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