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@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 > _______________________________________________ Users mailing list: Users@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