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

[Jan Pokorný]

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".

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.

-- 
Jan (Poki)
-------------- next part --------------
A non-text attachment was scrubbed...
Name: not available
Type: application/pgp-signature
Size: 819 bytes
Desc: not available
URL: <https://lists.clusterlabs.org/pipermail/users/attachments/20180410/b010e5ca/attachment-0002.sig>