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

[Jan Pokorný]

On 11/04/18 15:24 +0200, Klaus Wenninger wrote:
> On 04/11/2018 01:14 AM, Andrew Beekhof wrote:
>> you know... I wouldn't be opposed to running two copies (one for
>> config, one for status) and having the crmd combine the two before
>> sending to the PE.  i've toyed with the idea in the past to
>> alleviate some of the performance issues
> 
> And maybe even a 3rd one for attributes/key-storage - picking up the
> idea floating around in this thread as well.

Sounds like -datahubd would rhyme with all of these,
split covered with -confhubd and -statushubd, plus,
for instance, -dicthubd :-)

-- 
Poki


pgpOHXwS1dC2h.pgp
Description: PGP signature
___
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

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

[Klaus Wenninger]

On 04/11/2018 01:14 AM, Andrew Beekhof wrote:
>
>
> On Wed, Apr 11, 2018 at 12:42 AM, Ken Gaillot  > wrote:
>
> On Tue, 2018-04-10 at 08:50 +0200, Jehan-Guillaume de Rorthais wrote:
> > On Tue, 10 Apr 2018 00:54:01 +0200
> > Jan Pokorný >
> wrote:
> >
> > > On 09/04/18 12:10 -0500, Ken Gaillot wrote:
> > > > Based on the list discussion and feedback I could coax out of
> > > > others, I
> > > > will change the Pacemaker daemon names, including the log tags,
> > > > for
> > > > 2.0.0-rc3.
> > > >
> > > > I will add symlinks for the old names, to allow
> > > > help/version/metadata
> > > > calls in user scripts and higher-level tools to continue working
> > > > during
> > > > a transitional time. (Even if we update all known tools, we need
> > > > to
> > > > keep compatibility with existing versions for a good while.)
> > > >
> > > > I won't change the systemd unit file names or API library names,
> > > > since
> > > > they aren't one-to-one with the daemons, and will have a bigger
> > > > impact
> > > > on client apps.
> > > >
> > > > Here's my current plan:
> > > >
> > > > Old name  New name
> > > >   
> > > > pacemakerdpacemakerd
> > > > attrd pacemaker-attrd
> > > > cib   pacemaker-confd  
> > >
> > > Let's restate it: do we indeed want to reinforce a misnomer that
> > > CIB
> > > is (user) configuration only?
> >
> > Agree. FWIW, +1 for the "Infod" suggestion.
>
> I'm not opposed to it, but no option suggested so far intuitively
> covers what the cib does (including "cib"). All the daemons maintain
> information of some sort for querying and setting -- attrd maintains
> node attributes, stonithd maintains fence history, lrmd maintains a
> list of registered resources, etc.
>
> -confd, -cfgd, or -configd would emphasize the configuration aspect of
> cib's workload, at the cost of hiding the dynamic status aspect.
>
>
> you know... I wouldn't be opposed to running two copies (one for
> config, one for status) and having the crmd combine the two before
> sending to the PE.
> i've toyed with the idea in the past to alleviate some of the
> performance issues

And maybe even a 3rd one for attributes/key-storage - picking up the
idea floating
around in this thread as well.

>  
>
>
> -infod, -datad, or -stated (or cib) would emphasize the broadness of
> cib's workload, at the cost of being vague and including aspects of
> other daemons' responsibilities.
>
> -iod would emphasize cib's role as a disk I/O abstraction layer,
> at the
>  cost of downplaying the more essential configuration+status roles.
>
> Given all that, I'm leaning to -confd because configuration management
> is the cib's primary responsibility. 
>
>
> +1
>  
>
> The CIB stored on disk is entirely
> configuration (status is only in-memory), so it seems most
> intuitive to
> me. Keep in mind that the primary purpose of this renaming is to make
> the log files easier to read, so picture the name in front of a
> typical
> CIB log message (also considering that "info" is a log severity).
>
> But if there's a consensus otherwise, I'm willing to change it.
>
> >
> > > > crmd  pacemaker-controld
> > > > lrmd  pacemaker-execd
> > > > pengine   pacemaker-schedulerd
> > > > stonithd  pacemaker-fenced
> > > > pacemaker_remoted pacemaker-remoted
> > > >
> > > > I had planned to use the "pcmk-" prefix, but I kept thinking
> > > > about the
> > > > goal of making things more intuitive for novice users, and a
> > > > novice
> > > > user's first instinct will be to search the logs for
> > > > "pacemaker"  
> > >
> > > journalctl -u pacemaker?
> > >
> > > We could also ship an example syslog configuration that aggegrates
> > > messages from enumerated programs (that we know and user may not
> > > offhand)
> > > into a dedicated file (well, this would be quite redundant to
> > > native
> > > logging into the file).
> > >
> > > IOW, I wouldn't worry that much.
> >
> > +1
> >
> > My 2¢...
> --
> Ken Gaillot >
> ___
> 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
> 

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

[Andrew Beekhof]

On Wed, Apr 11, 2018 at 12:42 AM, Ken Gaillot  wrote:

> On Tue, 2018-04-10 at 08:50 +0200, Jehan-Guillaume de Rorthais wrote:
> > On Tue, 10 Apr 2018 00:54:01 +0200
> > Jan Pokorný  wrote:
> >
> > > On 09/04/18 12:10 -0500, Ken Gaillot wrote:
> > > > Based on the list discussion and feedback I could coax out of
> > > > others, I
> > > > will change the Pacemaker daemon names, including the log tags,
> > > > for
> > > > 2.0.0-rc3.
> > > >
> > > > I will add symlinks for the old names, to allow
> > > > help/version/metadata
> > > > calls in user scripts and higher-level tools to continue working
> > > > during
> > > > a transitional time. (Even if we update all known tools, we need
> > > > to
> > > > keep compatibility with existing versions for a good while.)
> > > >
> > > > I won't change the systemd unit file names or API library names,
> > > > since
> > > > they aren't one-to-one with the daemons, and will have a bigger
> > > > impact
> > > > on client apps.
> > > >
> > > > Here's my current plan:
> > > >
> > > > Old name  New name
> > > >   
> > > > pacemakerdpacemakerd
> > > > attrd pacemaker-attrd
> > > > cib   pacemaker-confd
> > >
> > > Let's restate it: do we indeed want to reinforce a misnomer that
> > > CIB
> > > is (user) configuration only?
> >
> > Agree. FWIW, +1 for the "Infod" suggestion.
>
> I'm not opposed to it, but no option suggested so far intuitively
> covers what the cib does (including "cib"). All the daemons maintain
> information of some sort for querying and setting -- attrd maintains
> node attributes, stonithd maintains fence history, lrmd maintains a
> list of registered resources, etc.
>
> -confd, -cfgd, or -configd would emphasize the configuration aspect of
> cib's workload, at the cost of hiding the dynamic status aspect.
>

you know... I wouldn't be opposed to running two copies (one for config,
one for status) and having the crmd combine the two before sending to the
PE.
i've toyed with the idea in the past to alleviate some of the performance
issues


>
> -infod, -datad, or -stated (or cib) would emphasize the broadness of
> cib's workload, at the cost of being vague and including aspects of
> other daemons' responsibilities.
>
> -iod would emphasize cib's role as a disk I/O abstraction layer, at the
>  cost of downplaying the more essential configuration+status roles.
>
> Given all that, I'm leaning to -confd because configuration management
> is the cib's primary responsibility.


+1


> The CIB stored on disk is entirely
> configuration (status is only in-memory), so it seems most intuitive to
> me. Keep in mind that the primary purpose of this renaming is to make
> the log files easier to read, so picture the name in front of a typical
> CIB log message (also considering that "info" is a log severity).
>
> But if there's a consensus otherwise, I'm willing to change it.
>
> >
> > > > crmd  pacemaker-controld
> > > > lrmd  pacemaker-execd
> > > > pengine   pacemaker-schedulerd
> > > > stonithd  pacemaker-fenced
> > > > pacemaker_remoted pacemaker-remoted
> > > >
> > > > I had planned to use the "pcmk-" prefix, but I kept thinking
> > > > about the
> > > > goal of making things more intuitive for novice users, and a
> > > > novice
> > > > user's first instinct will be to search the logs for
> > > > "pacemaker"
> > >
> > > journalctl -u pacemaker?
> > >
> > > We could also ship an example syslog configuration that aggegrates
> > > messages from enumerated programs (that we know and user may not
> > > offhand)
> > > into a dedicated file (well, this would be quite redundant to
> > > native
> > > logging into the file).
> > >
> > > IOW, I wouldn't worry that much.
> >
> > +1
> >
> > My 2¢...
> --
> Ken Gaillot 
> ___
> 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

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

[Jehan-Guillaume de Rorthais]

On Tue, 10 Apr 2018 18:08:55 +0200
Jan Pokorný  wrote:

> On 10/04/18 09:42 -0500, Ken Gaillot wrote:
> > On Tue, 2018-04-10 at 08:50 +0200, Jehan-Guillaume de Rorthais
> > wrote:  
> >> On Tue, 10 Apr 2018 00:54:01 +0200
> >> Jan Pokorný  wrote:  
> >>> On 09/04/18 12:10 -0500, Ken Gaillot wrote:  
>  I won't change the systemd unit file names or API library names,
>  since they aren't one-to-one with the daemons, and will have a
>  bigger impact on client apps.  
> 
> Regarding systemd, purely technical possibility is to exercise
> https://www.freedesktop.org/software/systemd/man/systemd.unit.html#Alias=
> that seems only helpfull if we would want to make pacemaker vs. pcmk
> compatibility affordable in the opposite direction than what is
> suggested below: if someone accidentally passes "pcmk" (under some
> impression from "pcmk-X" daemon spotted somewhere) as a service
> identifier instead of established "pacemaker".
> 
>  Here's my current plan:
>  
>  Old name  New name
>    
>  pacemakerdpacemakerd
>  attrd pacemaker-attrd
>  cib   pacemaker-confd    
> >>> 
> >>> Let's restate it: do we indeed want to reinforce a misnomer that
> >>> CIB is (user) configuration only?  
> >> 
> >> Agree. FWIW, +1 for the "Infod" suggestion.  
> > 
> > I'm not opposed to it, but no option suggested so far intuitively
> > covers what the cib does (including "cib"). All the daemons maintain
> > information of some sort for querying and setting -- attrd maintains
> > node attributes, stonithd maintains fence history, lrmd maintains a
> > list of registered resources, etc.
> > 
> > -confd, -cfgd, or -configd would emphasize the configuration aspect of
> > cib's workload, at the cost of hiding the dynamic status aspect.
> > 
> > -infod, -datad, or -stated (or cib) would emphasize the broadness of
> > cib's workload, at the cost of being vague and including aspects of
> > other daemons' responsibilities.
> > 
> > -iod would emphasize cib's role as a disk I/O abstraction layer, at the
> >  cost of downplaying the more essential configuration+status roles.  
> 
> Getting out of ideas: -datahubd.

This makes me think of DBus now :)

...This kind of makes sense though, as it gather and provide data from
multiple various process ;)

___
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

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

[Jan Pokorný]

On 10/04/18 09:42 -0500, Ken Gaillot wrote:
> On Tue, 2018-04-10 at 08:50 +0200, Jehan-Guillaume de Rorthais
> wrote:
>> On Tue, 10 Apr 2018 00:54:01 +0200
>> Jan Pokorný  wrote:
>>> On 09/04/18 12:10 -0500, Ken Gaillot wrote:
 I won't change the systemd unit file names or API library names,
 since they aren't one-to-one with the daemons, and will have a
 bigger impact on client apps.

Regarding systemd, purely technical possibility is to exercise
https://www.freedesktop.org/software/systemd/man/systemd.unit.html#Alias=
that seems only helpfull if we would want to make pacemaker vs. pcmk
compatibility affordable in the opposite direction than what is
suggested below: if someone accidentally passes "pcmk" (under some
impression from "pcmk-X" daemon spotted somewhere) as a service
identifier instead of established "pacemaker".

 Here's my current plan:
 
 Old name  New name
   
 pacemakerdpacemakerd
 attrd pacemaker-attrd
 cib   pacemaker-confd  
>>> 
>>> Let's restate it: do we indeed want to reinforce a misnomer that
>>> CIB is (user) configuration only?
>> 
>> Agree. FWIW, +1 for the "Infod" suggestion.
> 
> I'm not opposed to it, but no option suggested so far intuitively
> covers what the cib does (including "cib"). All the daemons maintain
> information of some sort for querying and setting -- attrd maintains
> node attributes, stonithd maintains fence history, lrmd maintains a
> list of registered resources, etc.
> 
> -confd, -cfgd, or -configd would emphasize the configuration aspect of
> cib's workload, at the cost of hiding the dynamic status aspect.
> 
> -infod, -datad, or -stated (or cib) would emphasize the broadness of
> cib's workload, at the cost of being vague and including aspects of
> other daemons' responsibilities.
> 
> -iod would emphasize cib's role as a disk I/O abstraction layer, at the
>  cost of downplaying the more essential configuration+status roles.

Getting out of ideas: -datahubd.

> Given all that, I'm leaning to -confd because configuration management
> is the cib's primary responsibility. The CIB stored on disk is entirely
> configuration (status is only in-memory), so it seems most intuitive to
> me. Keep in mind that the primary purpose of this renaming is to make
> the log files easier to read, so picture the name in front of a typical
> CIB log message (also considering that "info" is a log severity).
> 
> But if there's a consensus otherwise, I'm willing to change it.

-- 
Poki


pgp1VVL12pD3k.pgp
Description: PGP signature
___
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

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

[Ken Gaillot]

On Tue, 2018-04-10 at 08:50 +0200, Jehan-Guillaume de Rorthais wrote:
> On Tue, 10 Apr 2018 00:54:01 +0200
> Jan Pokorný  wrote:
> 
> > On 09/04/18 12:10 -0500, Ken Gaillot wrote:
> > > Based on the list discussion and feedback I could coax out of
> > > others, I
> > > will change the Pacemaker daemon names, including the log tags,
> > > for
> > > 2.0.0-rc3.
> > > 
> > > I will add symlinks for the old names, to allow
> > > help/version/metadata
> > > calls in user scripts and higher-level tools to continue working
> > > during
> > > a transitional time. (Even if we update all known tools, we need
> > > to
> > > keep compatibility with existing versions for a good while.)
> > > 
> > > I won't change the systemd unit file names or API library names,
> > > since
> > > they aren't one-to-one with the daemons, and will have a bigger
> > > impact
> > > on client apps.
> > > 
> > > Here's my current plan:
> > > 
> > > Old name  New name
> > >   
> > > pacemakerdpacemakerd
> > > attrd pacemaker-attrd
> > > cib   pacemaker-confd  
> > 
> > Let's restate it: do we indeed want to reinforce a misnomer that
> > CIB
> > is (user) configuration only?
> 
> Agree. FWIW, +1 for the "Infod" suggestion.

I'm not opposed to it, but no option suggested so far intuitively
covers what the cib does (including "cib"). All the daemons maintain
information of some sort for querying and setting -- attrd maintains
node attributes, stonithd maintains fence history, lrmd maintains a
list of registered resources, etc.

-confd, -cfgd, or -configd would emphasize the configuration aspect of
cib's workload, at the cost of hiding the dynamic status aspect.

-infod, -datad, or -stated (or cib) would emphasize the broadness of
cib's workload, at the cost of being vague and including aspects of
other daemons' responsibilities.

-iod would emphasize cib's role as a disk I/O abstraction layer, at the
 cost of downplaying the more essential configuration+status roles.

Given all that, I'm leaning to -confd because configuration management
is the cib's primary responsibility. The CIB stored on disk is entirely
configuration (status is only in-memory), so it seems most intuitive to
me. Keep in mind that the primary purpose of this renaming is to make
the log files easier to read, so picture the name in front of a typical
CIB log message (also considering that "info" is a log severity).

But if there's a consensus otherwise, I'm willing to change it.

> 
> > > crmd  pacemaker-controld
> > > lrmd  pacemaker-execd
> > > pengine   pacemaker-schedulerd
> > > stonithd  pacemaker-fenced
> > > pacemaker_remoted pacemaker-remoted
> > > 
> > > I had planned to use the "pcmk-" prefix, but I kept thinking
> > > about the
> > > goal of making things more intuitive for novice users, and a
> > > novice
> > > user's first instinct will be to search the logs for
> > > "pacemaker"  
> > 
> > journalctl -u pacemaker?
> > 
> > We could also ship an example syslog configuration that aggegrates
> > messages from enumerated programs (that we know and user may not
> > offhand)
> > into a dedicated file (well, this would be quite redundant to
> > native
> > logging into the file).
> > 
> > IOW, I wouldn't worry that much.
> 
> +1
> 
> My 2¢...
-- 
Ken Gaillot 
___
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

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

[Jehan-Guillaume de Rorthais]

On Tue, 10 Apr 2018 00:54:01 +0200
Jan Pokorný  wrote:

> On 09/04/18 12:10 -0500, Ken Gaillot wrote:
> > Based on the list discussion and feedback I could coax out of others, I
> > will change the Pacemaker daemon names, including the log tags, for
> > 2.0.0-rc3.
> > 
> > I will add symlinks for the old names, to allow help/version/metadata
> > calls in user scripts and higher-level tools to continue working during
> > a transitional time. (Even if we update all known tools, we need to
> > keep compatibility with existing versions for a good while.)
> > 
> > I won't change the systemd unit file names or API library names, since
> > they aren't one-to-one with the daemons, and will have a bigger impact
> > on client apps.
> > 
> > Here's my current plan:
> > 
> > Old name  New name
> >   
> > pacemakerdpacemakerd
> > attrd pacemaker-attrd
> > cib   pacemaker-confd  
> 
> Let's restate it: do we indeed want to reinforce a misnomer that CIB
> is (user) configuration only?

Agree. FWIW, +1 for the "Infod" suggestion.

> > crmd  pacemaker-controld
> > lrmd  pacemaker-execd
> > pengine   pacemaker-schedulerd
> > stonithd  pacemaker-fenced
> > pacemaker_remoted pacemaker-remoted
> > 
> > I had planned to use the "pcmk-" prefix, but I kept thinking about the
> > goal of making things more intuitive for novice users, and a novice
> > user's first instinct will be to search the logs for "pacemaker"  
> 
> journalctl -u pacemaker?
> 
> We could also ship an example syslog configuration that aggegrates
> messages from enumerated programs (that we know and user may not offhand)
> into a dedicated file (well, this would be quite redundant to native
> logging into the file).
> 
> IOW, I wouldn't worry that much.

+1

My 2¢...
___
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

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

[Kristoffer Grönlund]

Jehan-Guillaume de Rorthais  writes:

>
> I feel like you guys are talking of a solution that already exists and you
> probably already know, eg. "etcd".
>
> Etcd provides:
>
> * a cluster wide key/value storage engine
> * support quorum
> * key locking
> * atomic changes
> * REST API
> * etc...
>
> However, it requires to open a new TCP port, indeed :/
>

My main inspiration and reasoning is indeed to introduce the same
functionality provided by etcd into a corosync-based cluster without
having to add a parallel cluster consensus solution. Simply installing
etcd means 1) now you have two clusters, 2) etcd doesn't handle 2-node
clusters or fencing and doesn't degrade well to a single node, 3)
relying on the presence of the KV-store in pacemaker tools is not an
option unless pacemaker wants to make etcd a requirement.

Cheers,
Kristoffer

> Moreover, as a RA developer, I am currently messing with attrd weird
> behavior[1], so any improvement there is welcomed :)
>
> Cheers,
>
> [1] https://github.com/ClusterLabs/PAF/issues/131
>

-- 
// Kristoffer Grönlund
// kgronl...@suse.com
___
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

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

[Jan Pokorný]

On 09/04/18 12:10 -0500, Ken Gaillot wrote:
> Based on the list discussion and feedback I could coax out of others, I
> will change the Pacemaker daemon names, including the log tags, for
> 2.0.0-rc3.
> 
> I will add symlinks for the old names, to allow help/version/metadata
> calls in user scripts and higher-level tools to continue working during
> a transitional time. (Even if we update all known tools, we need to
> keep compatibility with existing versions for a good while.)
> 
> I won't change the systemd unit file names or API library names, since
> they aren't one-to-one with the daemons, and will have a bigger impact
> on client apps.
> 
> Here's my current plan:
> 
> Old name  New name
>   
> pacemakerdpacemakerd
> attrd pacemaker-attrd
> cib   pacemaker-confd

Let's restate it: do we indeed want to reinforce a misnomer that CIB
is (user) configuration only?

> crmd  pacemaker-controld
> lrmd  pacemaker-execd
> pengine   pacemaker-schedulerd
> stonithd  pacemaker-fenced
> pacemaker_remoted pacemaker-remoted
> 
> I had planned to use the "pcmk-" prefix, but I kept thinking about the
> goal of making things more intuitive for novice users, and a novice
> user's first instinct will be to search the logs for "pacemaker"

journalctl -u pacemaker?

We could also ship an example syslog configuration that aggegrates
messages from enumerated programs (that we know and user may not offhand)
into a dedicated file (well, this would be quite redundant to native
logging into the file).

IOW, I wouldn't worry that much.

> Most of the names stay under the convenient 15-character limit
> anyway.

-- 
Jan (Poki)


pgpVZPmnF2Ngs.pgp
Description: PGP signature
___
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

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

[Jehan-Guillaume de Rorthais]

On Tue, 03 Apr 2018 16:35:18 -0500
Ken Gaillot  wrote:

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

I feel like you guys are talking of a solution that already exists and you
probably already know, eg. "etcd".

Etcd provides:

* a cluster wide key/value storage engine
* support quorum
* key locking
* atomic changes
* REST API
* etc...

However, it requires to open a new TCP port, indeed :/

Moreover, as a RA developer, I am currently messing with attrd weird
behavior[1], so any improvement there is welcomed :)

Cheers,

[1] https://github.com/ClusterLabs/PAF/issues/131
___
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

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

[Ken Gaillot]

Based on the list discussion and feedback I could coax out of others, I
will change the Pacemaker daemon names, including the log tags, for
2.0.0-rc3.

I will add symlinks for the old names, to allow help/version/metadata
calls in user scripts and higher-level tools to continue working during
a transitional time. (Even if we update all known tools, we need to
keep compatibility with existing versions for a good while.)

I won't change the systemd unit file names or API library names, since
they aren't one-to-one with the daemons, and will have a bigger impact
on client apps.

Here's my current plan:

Old name  New name
  
pacemakerdpacemakerd
attrd pacemaker-attrd
cib   pacemaker-confd
crmd  pacemaker-controld
lrmd  pacemaker-execd
pengine   pacemaker-schedulerd
stonithd  pacemaker-fenced
pacemaker_remoted pacemaker-remoted

I had planned to use the "pcmk-" prefix, but I kept thinking about the
goal of making things more intuitive for novice users, and a novice
user's first instinct will be to search the logs for "pacemaker". Most
of the names stay under the convenient 15-character limit anyway.

On Wed, 2018-03-28 at 12:40 -0500, Ken Gaillot wrote:
> Hi all,
> 
> Andrew Beekhof brought up a potential change to help with reading
> Pacemaker logs.
> 
> Currently, pacemaker daemon names are not intuitive, making it
> difficult to search the system log or understand what each one does.
> 
> The idea is to rename the daemons, with a common prefix, and a name
> that better reflects the purpose.
> 
> I think it's a great idea, but we have to consider two drawbacks:
> 
> * I'm about to release 2.0.0-rc2, and it's late in the cycle for a
> major change. But if we don't do it now, it'll probably sit on the
> back
> burner for a few years, as it wouldn't make sense to introduce such a
> change shortly after a major bump.
> 
> * We can change *only* the names used in the logs, which will be
> simple, but give us inconsistencies with what shows up in "ps", etc.
> Or
> we can try to change everything -- process names, library names, API
> function/structure names -- but that will impact other projects such
> as
> sbd, crmsh, etc., potentially causing compatibility headaches.
> 
> What are your thoughts? Change or not? Now or later? Log tags, or
> everything?
> 
> And the fun part, what would we change them to ...
> 
> Beekhof suggested renaming "pengine" to "cluster-planner", as an
> example.
> 
> I think a prefix indicating pacemaker specifically would be better
> than
> "cluster-" for grepping and intuitiveness.
> 
> For intuitiveness, long names are better ("pacemaker-FUNCTION"). On
> the
> other hand, there's an argument for keeping names to 15 characters,
> which is the default "ps" column width, and a reasonable limit for
> log
> line tags. Maybe "pm-" or "pcmk-"? This prefix could also be used for
> library names.
> 
> Looking at other projects with server processes, most use the
> traditional "d" ending (for example, "rsyslogd"). A few add "-daemon"
> ("rtkit-daemon"), and others don't bother with any suffix ("gdm").
> 
> Here are the current names, with some example replacements:
> 
>  pacemakerd: PREFIX-launchd, PREFIX-launcher
> 
>  attrd: PREFIX-attrd, PREFIX-attributes
> 
>  cib: PREFIX-configd, PREFIX-state
> 
>  crmd: PREFIX-controld, PREFIX-clusterd, PREFIX-controller
> 
>  lrmd: PREFIX-locald, PREFIX-resourced, PREFIX-runner
> 
>  pengine: PREFIX-policyd, PREFIX-scheduler
> 
>  stonithd: PREFIX-fenced, PREFIX-stonithd, PREFIX-executioner
> 
>  pacemaker_remoted: PREFIX-remoted, PREFIX-remote
> 
-- 
Ken Gaillot 
___
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

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

[Kristoffer Grönlund]

Jan Pokorný  writes:

> /me keenly joins the bike-shedding
>
> What about pcmk-based/pcmk-infod.  First, we effectively tone down
> "common information/base" from the expanded CIB abbreviation[*1],
> and second, in the former case, we highlight that's the central point
> providing resident data glue (pcmk-datad?[*2]) amongst the other daemons.

pcmk-infod sounds pretty good to me, it indicates data management /
central information handling etc. Plus it contains at least part of one
of the words of the expansion of "CIB".

Cheers,
Kristoffer

-- 
// Kristoffer Grönlund
// kgronl...@suse.com
___
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

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

[Jan Pokorný]

On 06/04/18 09:09 +0200, Kristoffer Grönlund wrote:
> Ken Gaillot  writes:
>> On Tue, 2018-04-03 at 08:33 +0200, Kristoffer Grönlund wrote:
>>> Ken Gaillot  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.

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)

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

REST API daemon could be just another opt-in "addon" type of resource,
if need be.

[Or, considering shining new things, perhaps Varlink protocol:
https://github.com/varlink/documentation/wiki
might be appealing as well, assuming its HTTP proxy counterpart:
https://github.com/varlink/org.varlink.http
that can serve JSONs remotely.]

>> 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).
>
> [...]
> 
>>> 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 does this relate to csync2 I see frequently used together
with the cluster stack proper?  Would it be deprecated with
you intended long-term vision, or just using a modified back-end
to somehow utilize such key-value store?

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

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

[Jan Pokorný]

On 29/03/18 09:53 -0500, Ken Gaillot wrote:
> On Thu, 2018-03-29 at 10:35 +0200, Kristoffer Grönlund wrote:
>> Ken Gaillot  writes:
>>> Here are the current names, with some example replacements:
>>> 
>>>  pacemakerd: PREFIX-launchd, PREFIX-launcher
>>> 
>>>  attrd: PREFIX-attrd, PREFIX-attributes
>>> 
>>>  cib: PREFIX-configd, PREFIX-state
>>> 
>>>  crmd: PREFIX-controld, PREFIX-clusterd, PREFIX-controller
>>> 
>>>  lrmd: PREFIX-locald, PREFIX-resourced, PREFIX-runner
>>> 
>>>  pengine: PREFIX-policyd, PREFIX-scheduler
>>> 
>>>  stonithd: PREFIX-fenced, PREFIX-stonithd, PREFIX-executioner
>>> 
>>>  pacemaker_remoted: PREFIX-remoted, PREFIX-remote
>> 
>> Better to do it now rather than later. I vote in favor of changing
>> the
>> names. Yes, it'll mess up crmsh, but at least for distributions it's
>> just a simple search/replace patch to apply.
>> 
>> I would also vote in favour of sticking to the 15 character limit,
>> and
>> to use "pcmk" as the prefix. That leaves 11 characters for the name,
>> which should be enough for anyone ;)
>> 
>> My votes:
>> 
>> pacemakerd -> pcmk-launchd
>> attrd -> pcmk-attrd
>> cib -> pcmk-stated
>> crmd -> pcmk-controld
>> lrmd -> pcmk-resourced
>> pengine -> pcmk-schedulerd
>> stonithd -> pcmk-fenced
>> pacemaker_remoted -> pcmk-remoted
> 
> Those are all acceptable to me. I'd also be fine with pcmk-execd for
> lrmd, as suggested elsewhere.
> 
>> 
>> The one I'm the most divided about is cib. pcmk-cibd would also work.
> 
> That is the most difficult one, isn't it? :-)
> 
> Looking at it from another direction, maybe pcmk-iod, since it
> abstracts disk I/O for the other daemons? It doesn't encompass its
> entire purpose, but it points in the right direction.

/me keenly joins the bike-shedding

What about pcmk-based/pcmk-infod.  First, we effectively tone down
"common information/base" from the expanded CIB abbreviation[*1],
and second, in the former case, we highlight that's the central point
providing resident data glue (pcmk-datad?[*2]) amongst the other daemons.

[*1] I wonder for how many users CIB stands just for the cargo term
 encompassing further non-dissected "configuration stuff"
 (that there are also operational data likely being missed)
{*2] let's avoid "glue" in these names, there are already other
 connotations related to cluster

-- 
Jan (Poki)


pgpjAjglCwwmS.pgp
Description: PGP signature
___
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

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

[Kristoffer Grönlund]

Klaus Wenninger  writes:

>
> 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 ;-)
>

Bootstrapping is a problem I've thought about quite a bit.. It's
possible to implement in a number of ways, and it's not clear what's the
better approach. But I see a cluster-wide configuration database as an
enabler for better bootstrapping rather than a hurdle. If a new node
doesn't need a local copy of the database but can access the database
from an existing node, it would be possible for the new node to
bootstrap itself into the cluster with nothing more than remote access
to that database, so a single port to open and a single authentication
mechanism - this could certainly be handled over SSH just like pcsd and
crmsh implements it today.

But yes, at some point there needs to be communication channel opened..

-- 
// Kristoffer Grönlund
// kgronl...@suse.com
___
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

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

[Kristoffer Grönlund]

Ken Gaillot  writes:

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

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

[Andrew Beekhof]

On Tue, Apr 3, 2018 at 10:18 PM, Jehan-Guillaume de Rorthais <
j...@dalibo.com> wrote:

> On Tue, 3 Apr 2018 09:58:50 +1000
> Andrew Beekhof  wrote:
> > On Fri, Mar 30, 2018 at 8:36 PM, Jehan-Guillaume de Rorthais <
> > j...@dalibo.com> wrote:
> > > On Thu, 29 Mar 2018 09:32:41 +1100
> > > Andrew Beekhof  wrote:
> > > > On Thu, Mar 29, 2018 at 8:07 AM, Jehan-Guillaume de Rorthais <
> > > > j...@dalibo.com> wrote:
> [...]
> > > > Though by now there is surely a decent library for logging to files
> with
> > > > sub-second timestamps - if we could incorporate that into libqb and
> have
> > > > corosync use it too...
> > >
> > > In my opinion, this is neither the role of libqb
> >
> >
> > libqb has the logging library that pacemaker and corosync use.
> > it is absolutely where this change should happen
>
> I meant that this could be handled 100% by some external dedicated daemon,
> eg.
> syslog or journalctl.
>
> I was thinking about code simplification.
>
> [...]
>
> > > > then we could consider 1 log per daemon.
> > > > In which case, the outcome of the PREFIX-SUFFIX discussion above
> could
> > > > instead be used for /var/log/pacemaker/SUFFIX
> > >
> > > I think the best would be to have one log for Corosync, one log for
> > > Pacemaker (and all its sub-process/childs).
> > >
> > > Another good path toward understandable log file would be to hide what
> > > process is speaking. Experienced user will still know that "LOG:
> setting
> > > failcount to 3" comes from CRMd and "DEBUG1: failcount setted to 3"
> comes
> > > from attrd.
> > >
> > > However, this would probably be a mess...because again, the cause
> might be
> > > logged AFTER the effects/reaction :/
> >
> > why?  i've never seen that be the case
>
> Please find in attachment a demonstration of such behavior I found last
> week.
> Note that this comes from a Sles 12 SP1 using Pacemaker 1.1.13...People
> there
> were not able to upgrade the servers before we built the PoC together.
>
> First column is the order in the log file. Second column is how I would
> expect
> the messages to appear in the log.
>
> Eg. I would expect L.11
>
>   "pengine: notice: process_pe_message: Calculated Transition 29: [...]"
>
> Before CRMd begin to process it at L.6-10.
>
> Another exemple, I would expect LRMd L.35:
>
>   "lrmd:  notice: log_finished:  finished - rsc:pgsqld action:notify"
>
> Before the CRMd receive the result L.26...
>


No, none of these are out of order.


>
> Maybe this is something fixed in 1.1.18 or 2.0.0, I just couldn't find
> commit
> messages related to this when searching through them quickly.
>
> > > Maybe the solution is to log only messages from CRMD, where all the
> > > orchestration comes from. Everything else might go to some debug level
> if
> > > needed.
> >
> > sorry, that is a terrible idea
>
> I was throwing random ideas as I'm not familiar with internal architecture.
> Maybe it should be pacemakerd to gather messages from all other messages
> and
> spit them to stderr so they are captured by journald or redirected to a
> file...
>
> Regards,
___
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

Re: [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  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: 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

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

[Ken Gaillot]

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

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

> 
> Cheers,
> Kristoffer
> 
-- 
Ken Gaillot 
___
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

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

[Jehan-Guillaume de Rorthais]

On Tue, 3 Apr 2018 09:58:50 +1000
Andrew Beekhof  wrote:
> On Fri, Mar 30, 2018 at 8:36 PM, Jehan-Guillaume de Rorthais <
> j...@dalibo.com> wrote:  
> > On Thu, 29 Mar 2018 09:32:41 +1100
> > Andrew Beekhof  wrote:  
> > > On Thu, Mar 29, 2018 at 8:07 AM, Jehan-Guillaume de Rorthais <  
> > > j...@dalibo.com> wrote:  
[...]
> > > Though by now there is surely a decent library for logging to files with
> > > sub-second timestamps - if we could incorporate that into libqb and have
> > > corosync use it too...  
> >
> > In my opinion, this is neither the role of libqb  
> 
> 
> libqb has the logging library that pacemaker and corosync use.
> it is absolutely where this change should happen

I meant that this could be handled 100% by some external dedicated daemon, eg.
syslog or journalctl.

I was thinking about code simplification.

[...]

> > > then we could consider 1 log per daemon.
> > > In which case, the outcome of the PREFIX-SUFFIX discussion above could
> > > instead be used for /var/log/pacemaker/SUFFIX  
> >
> > I think the best would be to have one log for Corosync, one log for
> > Pacemaker (and all its sub-process/childs).
> >
> > Another good path toward understandable log file would be to hide what
> > process is speaking. Experienced user will still know that "LOG: setting
> > failcount to 3" comes from CRMd and "DEBUG1: failcount setted to 3" comes
> > from attrd.
> >
> > However, this would probably be a mess...because again, the cause might be
> > logged AFTER the effects/reaction :/
> 
> why?  i've never seen that be the case

Please find in attachment a demonstration of such behavior I found last week.
Note that this comes from a Sles 12 SP1 using Pacemaker 1.1.13...People there
were not able to upgrade the servers before we built the PoC together.

First column is the order in the log file. Second column is how I would expect
the messages to appear in the log.

Eg. I would expect L.11

  "pengine: notice: process_pe_message: Calculated Transition 29: [...]"

Before CRMd begin to process it at L.6-10.

Another exemple, I would expect LRMd L.35:

  "lrmd:  notice: log_finished:  finished - rsc:pgsqld action:notify"

Before the CRMd receive the result L.26...

Maybe this is something fixed in 1.1.18 or 2.0.0, I just couldn't find commit
messages related to this when searching through them quickly.

> > Maybe the solution is to log only messages from CRMD, where all the
> > orchestration comes from. Everything else might go to some debug level if
> > needed.
> 
> sorry, that is a terrible idea

I was throwing random ideas as I'm not familiar with internal architecture.
Maybe it should be pacemakerd to gather messages from all other messages and
spit them to stderr so they are captured by journald or redirected to a file...

Regards,1   1   14:15:50 slesHAtest1 pengine:info: LogActions:Leave   fence_sleshatest2   (Started slesHAtest1)
2   2   14:15:50 slesHAtest1 pengine:  notice: LogActions:Stopadmin_addr  (slesHAtest2)
3   3   14:15:50 slesHAtest1 pengine:info: LogActions:Leave   fence_sleshatest1   (Started slesHAtest2)
4   4   14:15:50 slesHAtest1 pengine:  notice: LogActions:Demote  pgsqld:0(Master -> Stopped slesHAtest2)
5   5   14:15:50 slesHAtest1 pengine:  notice: LogActions:Stoppgsqld:1(slesHAtest1)
6   8   14:15:50 slesHAtest1crmd:info: do_state_transition:   State transition S_POLICY_ENGINE -> S_TRANSITION_ENGINE [ input=I_PE_SUCCESS cause=C_IPC_MESSAGE origin=handle_response ]
7   9   14:15:50 slesHAtest1crmd:  notice: do_te_invoke:  Processing graph 29 (ref=pe_calc-dc-1522239350-121) derived from /var/lib/pacemaker/pengine/pe-input-105.bz2
8   11  14:15:50 slesHAtest1crmd:  notice: te_rsc_command:Initiating action 46: notify pgsqld_pre_notify_demote_0 on slesHAtest2
9   12  14:15:50 slesHAtest1crmd:  notice: te_rsc_command:Initiating action 48: notify pgsqld_pre_notify_demote_0 on slesHAtest1 (local)
10  10  14:15:50 slesHAtest1crmd:info: do_lrm_rsc_op: Performing key=48:29:0:99751e86-20f1-4ee7-83bf-6428b030ebc9 op=pgsqld_notify_0
11  6   14:15:50 slesHAtest1 pengine:  notice: process_pe_message:Calculated Transition 29: /var/lib/pacemaker/pengine/pe-input-105.bz2
12  7   14:15:50 slesHAtest1 cib:info: cib_process_request:   Forwarding cib_modify operation for section status to master (origin=local/crmd/161)
13  13  14:15:50 slesHAtest1lrmd:  notice: log_execute:   executing - rsc:pgsqld action:notify call_id:59
14  14  14:15:50 slesHAtest1 cib:info: cib_perform_op:Diff: --- 0.88.0 2
15  15  14:15:50 slesHAtest1 cib:info: cib_perform_op:Diff: +++ 0.88.1 (null)
16  16  14:15:50 slesHAtest1 cib:info: cib_perform_op:+  /cib:  @num_updates=1
17  17  14:15:50 slesHAtest1 cib:info: cib_perform_op:+  

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

[Kristoffer Grönlund]

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

Cheers,
Kristoffer

-- 
// Kristoffer Grönlund
// kgronl...@suse.com
___
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

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

[Andrew Beekhof]

On Fri, Mar 30, 2018 at 8:36 PM, Jehan-Guillaume de Rorthais <
j...@dalibo.com> wrote:

> On Thu, 29 Mar 2018 09:32:41 +1100
> Andrew Beekhof  wrote:
>
> > On Thu, Mar 29, 2018 at 8:07 AM, Jehan-Guillaume de Rorthais <
> > j...@dalibo.com> wrote:
> >
> > > On Wed, 28 Mar 2018 15:50:26 -0500
> > > Ken Gaillot  wrote:
> > > [...]
> > > > > >  pacemakerd: PREFIX-launchd, PREFIX-launcher
> > > > >
> > > > > pacemakerd, alone, sounds perfectly fine to me.
> > > >
> > > > Agreed -- but the argument against it is to allow something like
> "grep
> > > > pcmk /var/log/messages" to get everything.
> > >
> > > Then I would pick PREFIX-master... But then I would hate having a
> > > pcmk-master
> > > process :(
> > >
> > > Maybe all the logging information should be handled by one process so
> > > syslog/journald/stderr are happy?
> > >
> > > Despite it's multiprocess architecture, PostgreSQL either:
> > >
> > > * emit to syslog/journald using the same ident for all process
> > > * capture stderr of all process and redirect to one file.
> > >
> > > [...]
> > > > > >  cib: PREFIX-configd, PREFIX-state
> > > > >
> > > > > Tricky...It deals with both config and state...
> > > > >
> > > > > By the way, why in the first place the CIB messages must be in the
> > > > > log file?
> > > > > Filling logs with XML diffs resulting from other actions already
> > > > > logged earlier
> > > > > sounds like duplicated informations.
> > > >
> > > > They are kept out of the syslog, which is where most users are
> expected
> > > > to look. They are in the detail log, which is for more advanced
> > > > troubleshooting.
> > >
> > > oh ok, sorry.
> > >
> > > I just finished a day reading log file /var/log/pacemaker.log on a
> Suse 12
> > > SP1
> > > that was packed with XML diffs :/
> > >
> > > Maybe I should have checked /var/log/messages or the syslog setup...
> > >
> > > But honestly, I hate having mixed logs all packed in one same files
> > > like /var/log/messages :/
> > >
> >
> > Theres a very good reason for it though - the relative timing of events
> is
> > the only way to establish cause and effect.
>
> Yes. But sometime, messages are not so well mixed, with causes showing up
> after
> effects in logs...
>
> > Though by now there is surely a decent library for logging to files with
> > sub-second timestamps - if we could incorporate that into libqb and have
> > corosync use it too...
>
> In my opinion, this is neither the role of libqb


libqb has the logging library that pacemaker and corosync use.
it is absolutely where this change should happen



> or corosync...Or you would
> have to include some more configuration params to be able to set the log
> directory, file, format, rotation, etc.
>
> Maybe the easiest path is to rely on syslog/journald. They are both able
> to log
> with sub-second timestamps (at least journald do) and provide the
> administrator
> everything they need to deal with the logs.
>
> > then we could consider 1 log per daemon.
> > In which case, the outcome of the PREFIX-SUFFIX discussion above could
> > instead be used for /var/log/pacemaker/SUFFIX
>
> I think the best would be to have one log for Corosync, one log for
> Pacemaker
> (and all its sub-process/childs).
>
> Another good path toward understandable log file would be to hide what
> process
> is speaking. Experienced user will still know that "LOG: setting failcount
> to 3" comes from CRMd and "DEBUG1: failcount setted to 3" comes from attrd.
>
> However, this would probably be a mess...because again, the cause might be
> logged AFTER the effects/reaction :/
>

why?  i've never seen that be the case


>
> Maybe the solution is to log only messages from CRMD, where all the
> orchestration comes from. Everything else might go to some debug level if
> needed.
>

sorry, that is a terrible idea


>
> > > > The detail log messages are useful mainly because CIB changes can
> come
> > > > from external sources, not just cluster daemons,
> > >
> > > Sure, but a simple info messages explaining that «the CIB has been
> updated
> > > by
> > > tool "" » sound enough to me.
> > >
> >
> > to you, because you know what you changed.
> > anyone else reading the logs (ie. people doing support) hasn't got a clue
> > and knowing who changed what is crucial to understanding what the cluster
> > did and why
>
> I'm doing some support as well, infrequently. I suppose crm_report is
> probably
> enough to gather previous CIB and compare them.
>
>
___
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

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

[Ken Gaillot]

On Thu, 2018-03-29 at 10:35 +0200, Kristoffer Grönlund wrote:
> Ken Gaillot  writes:
> 
> > Hi all,
> > 
> > Andrew Beekhof brought up a potential change to help with reading
> > Pacemaker logs.
> > 
> > Currently, pacemaker daemon names are not intuitive, making it
> > difficult to search the system log or understand what each one
> > does.
> > 
> > The idea is to rename the daemons, with a common prefix, and a name
> > that better reflects the purpose.
> > 
> 
> [...]
> 
> > Here are the current names, with some example replacements:
> > 
> >  pacemakerd: PREFIX-launchd, PREFIX-launcher
> > 
> >  attrd: PREFIX-attrd, PREFIX-attributes
> > 
> >  cib: PREFIX-configd, PREFIX-state
> > 
> >  crmd: PREFIX-controld, PREFIX-clusterd, PREFIX-controller
> > 
> >  lrmd: PREFIX-locald, PREFIX-resourced, PREFIX-runner
> > 
> >  pengine: PREFIX-policyd, PREFIX-scheduler
> > 
> >  stonithd: PREFIX-fenced, PREFIX-stonithd, PREFIX-executioner
> > 
> >  pacemaker_remoted: PREFIX-remoted, PREFIX-remote
> 
> Better to do it now rather than later. I vote in favor of changing
> the
> names. Yes, it'll mess up crmsh, but at least for distributions it's
> just a simple search/replace patch to apply.
> 
> I would also vote in favour of sticking to the 15 character limit,
> and
> to use "pcmk" as the prefix. That leaves 11 characters for the name,
> which should be enough for anyone ;)
> 
> My votes:
> 
> pacemakerd -> pcmk-launchd
> attrd -> pcmk-attrd
> cib -> pcmk-stated
> crmd -> pcmk-controld
> lrmd -> pcmk-resourced
> pengine -> pcmk-schedulerd
> stonithd -> pcmk-fenced
> pacemaker_remoted -> pcmk-remoted

Those are all acceptable to me. I'd also be fine with pcmk-execd for
lrmd, as suggested elsewhere.

> 
> The one I'm the most divided about is cib. pcmk-cibd would also work.

That is the most difficult one, isn't it? :-)

Looking at it from another direction, maybe pcmk-iod, since it
abstracts disk I/O for the other daemons? It doesn't encompass its
entire purpose, but it points in the right direction.

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

> 
> Cheers,
> Kristoffer
> 
-- 
Ken Gaillot 
___
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

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

[Adam Spiers]

Kristoffer Gronlund  wrote:

Ken Gaillot  writes:

Hi all,

Andrew Beekhof brought up a potential change to help with reading
Pacemaker logs.


Great idea!

[snipped]


Better to do it now rather than later. I vote in favor of changing the
names. Yes, it'll mess up crmsh, but at least for distributions it's
just a simple search/replace patch to apply.

I would also vote in favour of sticking to the 15 character limit, and
to use "pcmk" as the prefix.


Agreed on all points.


That leaves 11 characters for the name, which should be enough for
anyone ;)


Haha, what could possibly go wrong ;-)  Nice reference to an infamous
software quote ;-)
___
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

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

[Kristoffer Grönlund]

Ken Gaillot  writes:

> Hi all,
>
> Andrew Beekhof brought up a potential change to help with reading
> Pacemaker logs.
>
> Currently, pacemaker daemon names are not intuitive, making it
> difficult to search the system log or understand what each one does.
>
> The idea is to rename the daemons, with a common prefix, and a name
> that better reflects the purpose.
>

[...]

> Here are the current names, with some example replacements:
>
>  pacemakerd: PREFIX-launchd, PREFIX-launcher
>
>  attrd: PREFIX-attrd, PREFIX-attributes
>
>  cib: PREFIX-configd, PREFIX-state
>
>  crmd: PREFIX-controld, PREFIX-clusterd, PREFIX-controller
>
>  lrmd: PREFIX-locald, PREFIX-resourced, PREFIX-runner
>
>  pengine: PREFIX-policyd, PREFIX-scheduler
>
>  stonithd: PREFIX-fenced, PREFIX-stonithd, PREFIX-executioner
>
>  pacemaker_remoted: PREFIX-remoted, PREFIX-remote

Better to do it now rather than later. I vote in favor of changing the
names. Yes, it'll mess up crmsh, but at least for distributions it's
just a simple search/replace patch to apply.

I would also vote in favour of sticking to the 15 character limit, and
to use "pcmk" as the prefix. That leaves 11 characters for the name,
which should be enough for anyone ;)

My votes:

pacemakerd -> pcmk-launchd
attrd -> pcmk-attrd
cib -> pcmk-stated
crmd -> pcmk-controld
lrmd -> pcmk-resourced
pengine -> pcmk-schedulerd
stonithd -> pcmk-fenced
pacemaker_remoted -> pcmk-remoted

The one I'm the most divided about is cib. pcmk-cibd would also work. 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...

Cheers,
Kristoffer

-- 
// Kristoffer Grönlund
// kgronl...@suse.com
___
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

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

[Andrew Beekhof]

On Thu, Mar 29, 2018 at 6:41 AM, Jehan-Guillaume de Rorthais <
j...@dalibo.com> wrote:

> On Wed, 28 Mar 2018 12:40:25 -0500
> Ken Gaillot  wrote:
>
> > Hi all,
> >
> > Andrew Beekhof brought up a potential change to help with reading
> > Pacemaker logs.
> >
> > Currently, pacemaker daemon names are not intuitive, making it
> > difficult to search the system log or understand what each one does.
> >
> > The idea is to rename the daemons, with a common prefix, and a name
> > that better reflects the purpose.
> >
> > I think it's a great idea, but we have to consider two drawbacks:
> >
> > * I'm about to release 2.0.0-rc2, and it's late in the cycle for a
> > major change. But if we don't do it now, it'll probably sit on the back
> > burner for a few years, as it wouldn't make sense to introduce such a
> > change shortly after a major bump.
> >
> > * We can change *only* the names used in the logs, which will be
> > simple, but give us inconsistencies with what shows up in "ps", etc. Or
> > we can try to change everything -- process names, library names, API
> > function/structure names -- but that will impact other projects such as
> > sbd, crmsh, etc., potentially causing compatibility headaches.
> >
> > What are your thoughts? Change or not?
>
> change
>
> > Now or later?
>
> I'm not sure how much work it involves during rc time... But I would pick
> now
> if possible.
>
> > Log tags, or everything?
>
> Everything.
>
> I'm from the PostgreSQL galaxy. In this galaxy, parameter
> "update_process_title" controls if PostgreSQL should set human readable
> process
> title and is "on" by default. In ps, it gives:
>
>   ioguix@firost:~$ ps f -o cmd -C postmaster
>   CMD
>   postmaster -D /home/ioguix/var/lib/pgsql/96
>\_ postgres: checkpointer process
>\_ postgres: writer process
>\_ postgres: wal writer process
>\_ postgres: autovacuum launcher process
>\_ postgres: stats collector process
>
> Some process might even add some useful information about their status,
> eg.:
> current replication status and location (process wal receiver/sender) or
> last
> WAL archived (process archiver).
>
> In source code, it boils down to this function:
>
> https://git.postgresql.org/gitweb/?p=postgresql.git;a=
> blob;f=src/backend/utils/misc/ps_status.c;h=5742de0802a54e38a2c2e3cfa8e8f4
> 45b6822883;hb=65c6b53991e1c56f6a0700ae26928962ddf2b9fe#l321


sbd also has similar code


>
>
> > And the fun part, what would we change them to ...
> >
> > Beekhof suggested renaming "pengine" to "cluster-planner", as an
> > example.
> >
> > I think a prefix indicating pacemaker specifically would be better than
> > "cluster-" for grepping and intuitiveness.
> >
> > For intuitiveness, long names are better ("pacemaker-FUNCTION"). On the
> > other hand, there's an argument for keeping names to 15 characters,
> > which is the default "ps" column width, and a reasonable limit for log
> > line tags. Maybe "pm-" or "pcmk-"? This prefix could also be used for
> > library names.
>
> "pcmk-*" sounds better to me. "cluster" has so many different definiion in
> people mind...
>
> > Looking at other projects with server processes, most use the
> > traditional "d" ending (for example, "rsyslogd"). A few add "-daemon"
> > ("rtkit-daemon"), and others don't bother with any suffix ("gdm").
> >
> > Here are the current names, with some example replacements:
> >
> >  pacemakerd: PREFIX-launchd, PREFIX-launcher
>
> pacemakerd, alone, sounds perfectly fine to me.
>
> >  attrd: PREFIX-attrd, PREFIX-attributes
>
> PREFIX-attributes
>

PREFIX-keystored ?


>
> >  cib: PREFIX-configd, PREFIX-state
>
> Tricky...It deals with both config and state...
>

PREFIX-datastore ?


>
> By the way, why in the first place the CIB messages must be in the log
> file?
>

Because its the only record of what changed and when.
Which is almost never important, except for those times when the
information is critical.
Which describes almost all of pacemaker's logging unfortunately.

On a related topic, I think if we made file logging mandatory then we could
move a lot more logs (including most of the cib logs) out of syslog.


> Filling logs with XML diffs resulting from other actions already logged
> earlier
> sounds like duplicated informations.
>

We generally only log configuration changes - which aren't logged in any
other form.


>
> I suppose most of the CIB logging messages could be set in debug level or
> replaced by a simple "cib updated with new {setup|status}"?
>
> >  crmd: PREFIX-controld, PREFIX-clusterd, PREFIX-controller
>
> PREFIX-controld
>
> >  lrmd: PREFIX-locald, PREFIX-resourced, PREFIX-runner
>
> PREFIX-executord? PREFIX-execd ?
>

PREFIX-executiond


> >  pengine: PREFIX-policyd, PREFIX-scheduler
>
> PREFIX-schedulerd
>
> > stonithd: PREFIX-fenced, PREFIX-stonithd, PREFIX-executioner
>
> I always disliked the STONITH acronym. For the same reasons, I
> dislike "executioner" as well. Moreover, some people might think it
> 

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

[Jehan-Guillaume de Rorthais]

On Wed, 28 Mar 2018 12:40:25 -0500
Ken Gaillot  wrote:

> Hi all,
> 
> Andrew Beekhof brought up a potential change to help with reading
> Pacemaker logs.
> 
> Currently, pacemaker daemon names are not intuitive, making it
> difficult to search the system log or understand what each one does.
> 
> The idea is to rename the daemons, with a common prefix, and a name
> that better reflects the purpose.
> 
> I think it's a great idea, but we have to consider two drawbacks:
> 
> * I'm about to release 2.0.0-rc2, and it's late in the cycle for a
> major change. But if we don't do it now, it'll probably sit on the back
> burner for a few years, as it wouldn't make sense to introduce such a
> change shortly after a major bump.
> 
> * We can change *only* the names used in the logs, which will be
> simple, but give us inconsistencies with what shows up in "ps", etc. Or
> we can try to change everything -- process names, library names, API
> function/structure names -- but that will impact other projects such as
> sbd, crmsh, etc., potentially causing compatibility headaches.
> 
> What are your thoughts? Change or not? 

change

> Now or later?

I'm not sure how much work it involves during rc time... But I would pick now
if possible.

> Log tags, or everything?

Everything.

I'm from the PostgreSQL galaxy. In this galaxy, parameter
"update_process_title" controls if PostgreSQL should set human readable process
title and is "on" by default. In ps, it gives:

  ioguix@firost:~$ ps f -o cmd -C postmaster
  CMD
  postmaster -D /home/ioguix/var/lib/pgsql/96
   \_ postgres: checkpointer process   
   \_ postgres: writer process   
   \_ postgres: wal writer process   
   \_ postgres: autovacuum launcher process   
   \_ postgres: stats collector process   

Some process might even add some useful information about their status, eg.:
current replication status and location (process wal receiver/sender) or last
WAL archived (process archiver).

In source code, it boils down to this function:

https://git.postgresql.org/gitweb/?p=postgresql.git;a=blob;f=src/backend/utils/misc/ps_status.c;h=5742de0802a54e38a2c2e3cfa8e8f445b6822883;hb=65c6b53991e1c56f6a0700ae26928962ddf2b9fe#l321

> And the fun part, what would we change them to ...
> 
> Beekhof suggested renaming "pengine" to "cluster-planner", as an
> example.
> 
> I think a prefix indicating pacemaker specifically would be better than
> "cluster-" for grepping and intuitiveness.
> 
> For intuitiveness, long names are better ("pacemaker-FUNCTION"). On the
> other hand, there's an argument for keeping names to 15 characters,
> which is the default "ps" column width, and a reasonable limit for log
> line tags. Maybe "pm-" or "pcmk-"? This prefix could also be used for
> library names.

"pcmk-*" sounds better to me. "cluster" has so many different definiion in
people mind...

> Looking at other projects with server processes, most use the
> traditional "d" ending (for example, "rsyslogd"). A few add "-daemon"
> ("rtkit-daemon"), and others don't bother with any suffix ("gdm").
> 
> Here are the current names, with some example replacements:
> 
>  pacemakerd: PREFIX-launchd, PREFIX-launcher

pacemakerd, alone, sounds perfectly fine to me.

>  attrd: PREFIX-attrd, PREFIX-attributes

PREFIX-attributes

>  cib: PREFIX-configd, PREFIX-state

Tricky...It deals with both config and state...

By the way, why in the first place the CIB messages must be in the log file?
Filling logs with XML diffs resulting from other actions already logged earlier
sounds like duplicated informations.

I suppose most of the CIB logging messages could be set in debug level or
replaced by a simple "cib updated with new {setup|status}"?

>  crmd: PREFIX-controld, PREFIX-clusterd, PREFIX-controller

PREFIX-controld

>  lrmd: PREFIX-locald, PREFIX-resourced, PREFIX-runner

PREFIX-executord? PREFIX-execd ?

>  pengine: PREFIX-policyd, PREFIX-scheduler

PREFIX-schedulerd

> stonithd: PREFIX-fenced, PREFIX-stonithd, PREFIX-executioner

I always disliked the STONITH acronym. For the same reasons, I
dislike "executioner" as well. Moreover, some people might think it actually
"executes" some process in the sense of "running".

I would definitely vote for PREFIX-fenced

>  pacemaker_remoted: PREFIX-remoted, PREFIX-remote

PREFIX-remoted


My 2¢,
___
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

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

[Ken Gaillot]

Hi all,

Andrew Beekhof brought up a potential change to help with reading
Pacemaker logs.

Currently, pacemaker daemon names are not intuitive, making it
difficult to search the system log or understand what each one does.

The idea is to rename the daemons, with a common prefix, and a name
that better reflects the purpose.

I think it's a great idea, but we have to consider two drawbacks:

* I'm about to release 2.0.0-rc2, and it's late in the cycle for a
major change. But if we don't do it now, it'll probably sit on the back
burner for a few years, as it wouldn't make sense to introduce such a
change shortly after a major bump.

* We can change *only* the names used in the logs, which will be
simple, but give us inconsistencies with what shows up in "ps", etc. Or
we can try to change everything -- process names, library names, API
function/structure names -- but that will impact other projects such as
sbd, crmsh, etc., potentially causing compatibility headaches.

What are your thoughts? Change or not? Now or later? Log tags, or
everything?

And the fun part, what would we change them to ...

Beekhof suggested renaming "pengine" to "cluster-planner", as an
example.

I think a prefix indicating pacemaker specifically would be better than
"cluster-" for grepping and intuitiveness.

For intuitiveness, long names are better ("pacemaker-FUNCTION"). On the
other hand, there's an argument for keeping names to 15 characters,
which is the default "ps" column width, and a reasonable limit for log
line tags. Maybe "pm-" or "pcmk-"? This prefix could also be used for
library names.

Looking at other projects with server processes, most use the
traditional "d" ending (for example, "rsyslogd"). A few add "-daemon"
("rtkit-daemon"), and others don't bother with any suffix ("gdm").

Here are the current names, with some example replacements:

 pacemakerd: PREFIX-launchd, PREFIX-launcher

 attrd: PREFIX-attrd, PREFIX-attributes

 cib: PREFIX-configd, PREFIX-state

 crmd: PREFIX-controld, PREFIX-clusterd, PREFIX-controller

 lrmd: PREFIX-locald, PREFIX-resourced, PREFIX-runner

 pengine: PREFIX-policyd, PREFIX-scheduler

 stonithd: PREFIX-fenced, PREFIX-stonithd, PREFIX-executioner

 pacemaker_remoted: PREFIX-remoted, PREFIX-remote

-- 
Ken Gaillot 
___
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