[ClusterLabs Developers] Impact of changing Pacemaker daemon names on other projects?

[Ken Gaillot]

On Tue, 2018-04-17 at 07:32 +0200, Kristoffer Grönlund wrote:
> Ken Gaillot <kgaillot at redhat.com> writes:
> 
> > Hi all,
> > 
> > As I'm sure you've seen, there is a strong sentiment on the users
> > list
> > to change all the Pacemaker daemon names in Pacemaker 2.0.0, mainly
> > to
> > make it easier to read the logs.
> > 
> > This will obviously affect any other scripts and projects that look
> > for
> > the old names. I'd like to hear more developer input on how far we
> > should go with this, and how much or little of a headache it will
> > cause. I'm interested in both the public projects that use
> > pacemaker
> > (crmsh, pcs, sbd, dlm, openstack) and one-off scripts that people
> > commonly put together.
> > 
> > In order of minimum impact to maximum impact, we could actually do
> > this
> > in stages:
> > 
> > 1. Log tags: This hopefully wouldn't affect anyone. For example,
> > from
> > 
> > Mar 12 12:10:49 [11120] node1 pacemakerd:     info:
> > crm_log_init:     Changed active directory to
> > /var/lib/pacemaker/cores
> > 
> > to
> > 
> > Mar 12 12:10:49 [11120] node1 pcmk-launchd:     info:
> > crm_log_init:     Changed active directory to
> > /var/lib/pacemaker/cores
> > 
> 
> Perhaps surprisingly, this is probably the part which affects crmsh
> the
> most... For the history explorer we do a lot of log scanning and have
> a
> set of regexes to match various interesting outputs from
> pacemaker. However, we already handle changes in this format between
> versions, so it's just a matter of adding another set of regexes for
> the
> new version.
> 
> More details: https://github.com/ClusterLabs/crmsh/blob/master/crmsh/
> log_patterns.py
> 
> There are some other places that have similar things, like
> logparser.py.

Yes, cts is in the same boat. I hope to have rc3 out with the new names
within a week, so you can start playing with it.

> > 2. Process names: what shows up in "ps". I'm hoping this would
> > affect
> > very little outside code, so we can at least get this far.
> 
> This will also need some updates in crmsh, but not too many. There is
> a
> list of programs to query for metadata, just adding the new names to
> that list should be sufficient for example.

I'm going to put symlinks at the old names for this reason, so older
versions of crmsh/pcs/etc. will continue to work. Newer versions should
probably do something like "if executable with new name exists, use it,
else if executable with old name exists, use that".

> > 3. Library names: for example, -lstonithd to -lpcmk-fencing. Other
> > projects would need their configure script to auto-detect which is
> > available. Not difficult, but it makes all older versions of other
> > projects incompatible with Pacemaker 2.0. This is mostly what I
> > want
> > feedback on, whether this is a good idea. The only advantage is
> > consistency and clarity.
> 
> I would just move to the new names and require 2.0 to build the newer
> versions.. so it would be a compatibility break both ways.

I've decided against this because it will be a bigger project. The
libraries aren't one-to-one with the daemons, so looking at them will
open up potentially bigger changes (like combining some of the
libraries into one). My plate is already too full for the 2.0.0 time
frame, and it's not a user-visible change, so we can revisit it at some
future 2.1 release.

> > 4. Public API symbols: for example, crm_meta_name() ->
> > pcmk_meta_name(). This would be a huge project with huge impact,
> > and
> > will definitely not be done for 2.0.0. We would immediately start
> > using
> > the new convention for new API symbols, and more slowly update
> > existing
> > ones (with compatibility wrappers for the old names).
> 
> Not too much opinion here but seems questionable, not sure how much
> benefit it would bring and there are clear downsides to doing it.

Yep, we'll only start using this for newly added functions/structures.
Again maybe at some future 2.1 we can revisit older names.
-- 
Ken Gaillot <kgaillot at redhat.com>