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

[Klaus Wenninger]

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