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

[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 at clusterlabs.org
> https://lists.clusterlabs.org/mailman/listinfo/developers