[RFC] OCF modularity with optional standardized addon profiles

[jnpkrn]

I touched this topic recently [1]:

[...] an idea of modularizing OCF standard with base + addon
profiles plus the way how the agents would express which addon
profile they require somewhere in the metadata.

Hence, existing agents calling out to attrd_updater would start
requiring node-annotations (or node-annotations-1.6 if
particular minimal version of the standard was required) addon profile,
would start sourcing $CRM_PROFILE_LIB/node-annotations.sh file (in
case of shell implementation, similar mechanism for other supported
languages) provided by given cluster resource manager (CRM) and
containing implementations of functions prescribed in the standard
(respective addon profile), e.g. ocfaddon_na_set.

or ocfao_na_set for a shorter prefix

Of course, CRM groking that the resource requires addon profiles
it cannot satisfy would declare a failure with the resource right
away.

[...]

But I have very little insights into how much demand it is there
for something like this today.

Suggested profiles to legitimize current beyond-standard inverse
dependencies on CRM:

• node-annotations

  • agents/resources currently calling out to attrd_updater
    (per the initial idea above)

• multicluster-tickets

  • agents/resources calling out to crm_ticket (and perhaps more)

Note that as mentioned, the mentioned delegation to particular
executables would be abstraced per particular CRM, allowing
interoperability with any CRM opting to deliver such addon
functionality and also easier testing (extensions to ocft?).

Also current clones and multistate agents could be fully legitimized
when turned into OCF + addon profile(s) requirement on the interface
with CRM. This would require more robust coverage of the use cases,
as, e.g. IPaddr2 can optionally become clone, but it doesn't need
to be run like that.

[1] https://oss.clusterlabs.org/pipermail/users/2018-April/014815.html

[krig]

I have to say that for me personally I would prefer not to complicate things in this manner. I have seen specs before that enable modules and pluggable behavior, and the effect has always been two things:

1. In practice, one set of modules becomes the de-facto standard that implementations are forced to adhere to.
2. The spec becomes overly complex due to layers of abstraction introduced to enable modularization, and thus more difficult to use and conform to.

I'm a strong proponent of simplicity over functionality. To the point of wishing that the OCF spec 2.0 could be smaller than the first iteration and remove features that have proven themselves to be less useful than first thought. One example is the lang="en..." attribute which as far as I know has never been used or supported by any tool or implementation.

[jnpkrn]

See for example how Wayland leverages this simple core (simplicity!)
+ modular extensions, moreover split between stable and unstable
subsets: https://cgit.freedesktop.org/wayland/wayland-protocols/tree/

Sadly some graphical toolkits with vested interest in Wayland already
started to roll their own proprietary protocol extensions (doesn't this
resemble pacemaker's privatization of OCF?) so hopefully the common
sense and the convergence on the common functionality will prevail
eventually, meaning less fragmentation and more overall benefit.

[krig]

Yeah, there’s a difficult balance to strike between preserving a simple and stable specification and allowing changes to the spec to avoid fragmentation and implementations departing from the spec.. On the other hand, the spec is powerless to prevent an implementation from making incompatible changes that simply aren’t any good and shouldn’t go into the spec anyway.

[jnpkrn]

Another "profile" that might useful, say restart-optimizing-1:

https://lists.clusterlabs.org/pipermail/users/2019-December/026681.html

In fact, for this very use case, one might argue that adding an
extra argument after stop (e.g. stop start-pending=1) would
fil the bill in a compatible manner, however:

• stacking any additional arguments after the initial action
  is basically undefined, and it'd be fair and legitimate if
  agents casually treated that as error

• profound, system-level modifiers shall be visible (previous
  point fulfills that, however yet another environment variable
  that is basically hidden across the execution audit would
  not make a cut)

• any avoidance from the actual "profile" or similar infrastructure
  would just shift the problem around -- it appears this infrastructure
  would be a systemic solution to many open loops we currently have
  on an OCF-integration front (not facing the challenge directly
  so as to open new opportunities, but playing it all around)