[ClusterLabs] Pacemaker's additional services for distributed applications (Was: Possible idea for 2.0.0: renaming the Pacemaker daemons)

[Klaus Wenninger]

On 04/10/2018 11:27 AM, Jan Pokorný wrote:
> On 06/04/18 12:24 +0200, Jan Pokorný wrote:
>> On 06/04/18 09:09 +0200, Kristoffer Grönlund wrote:
>>>>> The idea is to provide a more generalized key-value store that
>>>>> other applications built on top of pacemaker can use. Something
>>>>> like a HTTP REST API to a key-value store with transactional
>>>>> semantics provided by the cluster. My understanding so far is that
>>>>> the CIB is too heavy to support that kind of functionality well,
>>>>> and besides that the interface is not convenient for non-cluster
>>>>> applications.
>> First, from the bigger picture perspective, let's figure out if this is
>> envisioned as something mandatory for each and every pacemaker-charged
>> stack, or whether this is actually an optional part helping just the
>> particular use cases you have in mind.
>>
>> * Do the casual cluster-awarizing agents need to synchronize state way
>>   beyond what they can do now with node attributes and various run-time
>>   indicators passed by cluster resource manager directly?
>>
>>   - Wouldn't using corosync infrastructure directly serve better in
>>     that case (as mentioned by Klaus)?
>>
>> * Or is there a shift from "pacemaker, the executioner of the jobs
>>   within cluster to achieve configured goals, high-level servant of
>>   the users" to "pacemaker, the distributed systems enabler for
>>   otherwise single host software, primarily low-level servant of such
>>   applications stacked on top"?
>>   
>>   - Isn't this rather an opportunity for new "addon" type of in-CIB
>>     resource that would have much more intimate contact with
>>     pacemaker, would rather act as a sibling of other pacemaker
>>     daemons (which we can effectively understand as default clones
>>     with unlimited restarts upon crash), but would be
>>     started/plugged-in after all these native ones, could possibly
>>     live outside of the pacemaker's own lifetime (in which case it
>>     would use a backup communication channel, perhaps limited just
>>     to bootstrapping procedure), could live in the project on its
>>     own given that "addon" API would be well-defined, and importantly,
>>     would be completely opt-in for those happy with the original
>>     pacemaker use case (i.e., more akin to UNIX philosophy)
> Some synergies when thinking about the above two directions suddenly
> start to pop:
>
> 1. Actually we can consider "attrd" as one such "addon" on its own, it's
>    an implicit one with pacemaker.
>
> 2. Historically, there's is an ever widening conceptual gap in
>    interoperability of OCF standard applications -- the number of
>    truly universal OCF agents may be quite low, since for instance
>    they hardcode "attrd_updater" invocations that is very pacemaker
>    specific.
>
> !. + 2. now leads to 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".

I like the idea of some abstraction between tooling used
and actual intent.
That might be useful as well even within a pacemaker-cluster
when we have different types of nodes (currently remote-nodes
and full-cluster-nodes).

>
> Of course, CRM groking that the resource requires addon profiles
> it cannot satisfy would declare a failure with the resource right
> away.
>
> So if any resource would require sketched "distributed-keyvalue-store",
> it's runnability in the context of pacemaker would depend on whether
> suitable addon was configured in the CIB (remember: opt-in) and
> is healthy.  To avoid confusion, it would then make sense to name
> pacemaker-only addons with a clear prefix, e.g. "pcmk:rest-server".
>
> But I have very little insights into how much demand it is there
> for something like this today.
>
>
>
> _______________________________________________
> Users mailing list: Users at clusterlabs.org
> https://lists.clusterlabs.org/mailman/listinfo/users
>
> Project Home: http://www.clusterlabs.org
> Getting started: http://www.clusterlabs.org/doc/Cluster_from_Scratch.pdf
> Bugs: http://bugs.clusterlabs.org
>