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

2018-04-16 Thread Kristoffer Grönlund 
Ken Gaillot  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.

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

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

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

Cheers,
Kristoffer

> -- 
> Ken Gaillot 
> ___
> Developers mailing list
> Developers@clusterlabs.org
> https://lists.clusterlabs.org/mailman/listinfo/developers

-- 
// Kristoffer Grönlund
// kgronl...@suse.com
___
Developers mailing list
Developers@clusterlabs.org
https://lists.clusterlabs.org/mailman/listinfo/developers

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

2018-04-16 Thread Jan Pokorný 
On 16/04/18 14:32 +0200, Klaus Wenninger wrote:
> On 04/16/2018 01:52 PM, Jan Pokorný wrote:
>> On 29/03/18 11:13 -0500, Ken Gaillot wrote:
>>> 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).
>> 
>> Value added here would be putting some commitment behind the "true
>> public API" when the symbols get sifted carefully, leaving some other
>> naming prefixes reserved for private only ones (without any commitment
>> whatsoever).
> 
> Like e.g. pcmk_* & pcmkpriv_*  (preferably something shorter
> for the latter) ?

Yes, something like that (pcmk_* vs. anything not starting with "pcmk_"
might suffice), which would allow for compiling library(ies) twice
-- once for public use (only "public API" symbols visible), once
for pacemaker's own usage (libpcmk_foo_private.so, everything non-static
visible).  That might be a first step towards something supportable,
start with literally nothing in the public version, gradually grow the
numbers, with almost no hassle other than adding symbols to an external
list and/or renaming formerly private-only symbols so as to match the
regexp/glob.  All native executables would naturaly link against
libpcmk_foo_private versions.  Later on, these can be merged or
otherwise restructured.

-- 
Poki


pgprD265u_74B.pgp
Description: PGP signature
___
Developers mailing list
Developers@clusterlabs.org
https://lists.clusterlabs.org/mailman/listinfo/developers

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

2018-04-16 Thread Klaus Wenninger 
On 04/16/2018 01:52 PM, Jan Pokorný wrote:
> On 29/03/18 11:13 -0500, Ken Gaillot wrote:
>> 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
>>
>> 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.
>>
>> 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.
> Good news is that pkg-config/pkgconf (PKG_CHECK_MODULES et al.
> Autoconf macros) honours names of *.pc files, hence compatibility
> can be maintained with symlinks.
>
>> 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).
> Value added here would be putting some commitment behind the "true
> public API" when the symbols get sifted carefully, leaving some other
> naming prefixes reserved for private only ones (without any commitment
> whatsoever).
Like e.g. pcmk_* & pcmkpriv_*  (preferably something shorter
for the latter) ?

>
>
> ___
> Developers mailing list
> Developers@clusterlabs.org
> https://lists.clusterlabs.org/mailman/listinfo/developers

___
Developers mailing list
Developers@clusterlabs.org
https://lists.clusterlabs.org/mailman/listinfo/developers

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

2018-04-16 Thread Jan Pokorný 
On 29/03/18 11:13 -0500, Ken Gaillot wrote:
> 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
> 
> 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.
> 
> 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.

Good news is that pkg-config/pkgconf (PKG_CHECK_MODULES et al.
Autoconf macros) honours names of *.pc files, hence compatibility
can be maintained with symlinks.

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

Value added here would be putting some commitment behind the "true
public API" when the symbols get sifted carefully, leaving some other
naming prefixes reserved for private only ones (without any commitment
whatsoever).

-- 
Poki


pgpbl4MhZnKdK.pgp
Description: PGP signature
___
Developers mailing list
Developers@clusterlabs.org
https://lists.clusterlabs.org/mailman/listinfo/developers