[ClusterLabs] Pacemaker's additional services for distributed applications (Was: Possible idea for 2.0.0: renaming the Pacemaker daemons)
kwenning at redhat.com
Tue Apr 10 05:45:50 EDT 2018
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
>> 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
> !. + 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
> Of course, CRM groking that the resource requires addon profiles
> it cannot satisfy would declare a failure with the resource right
> 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
> Project Home: http://www.clusterlabs.org
> Getting started: http://www.clusterlabs.org/doc/Cluster_from_Scratch.pdf
> Bugs: http://bugs.clusterlabs.org
More information about the Users