On 04/03/2018 11:35 PM, Ken Gaillot wrote: > On Tue, 2018-04-03 at 08:33 +0200, Kristoffer Grönlund wrote: >> Ken Gaillot <[email protected]> writes: >> >>>> I >>>> would vote against PREFIX-configd as compared to other cluster >>>> software, >>>> I would expect that daemon name to refer to a more generic >>>> cluster >>>> configuration key/value store, and that is something that I have >>>> some >>>> hope of adding in the future ;) So I'd like to keep "config" or >>>> "database" for such a possible future component... >>> What's the benefit of another layer over the CIB? >>> >> 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. > My first impression is that it sounds like a good extension to attrd, > cluster-wide attributes instead of node attributes. (I would envision a > REST API daemon sitting in front of all the daemons without providing > any actual functionality itself.) > > The advantage to extending attrd is that it already has code to > synchronize attributes at start-up, DC election, partition healing, > etc., as well as features such as write dampening. > > Also cib -> pcmk-configd is very popular :) Aah funny ... have a very similar answer sitting in my drafts folder I hadn't completed ...
Maybe add to the advantages side that it doesn't introduce additional network-traffic that needs additional firewall rules, encryption and alike. Although for these it might have been enough to use corosync or even knet in some other way. > >> My most immediate applications for that would be to build file >> syncing >> into the cluster and to avoid having to have an extra communication >> layer for the UI. > How would file syncing via a key-value store work? Read that a couple of times as well ... You meant it the other way round - like implement the key-value store via file syncing - right? One thing I thought over as well is some kind of a chicken & egg issue arising when you want to use the syncing-mechanism so setup (bootstrap) the cluster. So something like the ssh-mechanism pcsd is using might still be needed. The file-syncing approach would have the data easily available locally prior to starting the actual cluster-wide syncing. Well ... no solutions or anything ... just a few thoughts I had on that issue ... 25ct max ;-) Regards, Klaus > > One of the key hurdles in any cluster-based sync is > authentication/authorization. Authorization to use a cluster UI is not > necessarily equivalent to authorization to transfer arbitrary files as > root. > >> Cheers, >> Kristoffer >> _______________________________________________ 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
