[ClusterLabs] Possible idea for 2.0.0: renaming the Pacemaker daemons

[Kristoffer Grönlund]

Ken Gaillot <kgaillot at redhat.com> writes:

> On Tue, 2018-04-03 at 08:33 +0200, Kristoffer Grönlund wrote:
>> Ken Gaillot <kgaillot at redhat.com> 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.

Yes, I've considered that as well and yes, I think it could make
sense. I need to gain a better understanding of the current attrd
implementation to see how to make it do what I want. The configd
name/part comes into play when bringing in syncing data beyond the
key-value store (see below).

>
> Also cib -> pcmk-configd is very popular :)
>

I can live with it. ;)

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

Yeah, the key-value store wouldn't be enough to implement file
syncing, but it could potentially be the mechanism by which the file
syncing implementation maintains its state. I'm somewhat conflating two
things that I want that are both related to syncing configuration beyond
the cluster daemon itself across the cluster.

I don't see authentication/authorization as a hurdle or blocker, but
it's certainly something that needs to be considered. Clearly a
less-privileged user shouldn't be able to configure syncing of
root-owned files across the cluster.

-- 
// Kristoffer Grönlund
// kgronlund at suse.com