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)
pgpU4bbMQCYfT.pgp
Description: PGP signature
_______________________________________________ Users mailing list: [email protected] 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
