[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)