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

[Jan Pokorný]

On 11/04/18 11:03 -0500, Ken Gaillot wrote:
> On Wed, 2018-04-11 at 08:49 +0200, Ulrich Windl wrote:
>>>>> Ken Gaillot <kgaillot at redhat.com> schrieb am 09.04.2018 um
>>>>> 19:10 in Nachricht
>>> 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.
>> 
>> If the user searches logs before reading the docs, the user has a
>> more severe problem IMHO.
> 
> Even after reading docs, when someone starts troubleshooting a problem,
> they're going to look at the logs (which may be grepping a file,
> running journalctl, typing a string into a log collector's search bar,
> etc.). Anyone's first instinct will be to search for the name of the
> program. People will learn to adapt to whatever we pick if they use it
> often enough, but the goal of this rename is to make things intuitive
> enough that people don't need to remember bits of pacemaker trivia (and
> the person filling in for the person who normally maintains the cluster
> while they're on vacation doesn't pull their hair out).

Another perspective is this: advent of machine learning and similar
advancements means that shift towards structured logging is
unrefutable (why to lose energy on human-friendly data serialization
only to be turned back to something edible by machines to feed their
inference rules/analytical perspective -- even if it's just a user's
script, accessing some fields directly will make one's life easier).

Long-term embracing that seems more viable to me than micro-optimizing
with a full prefix, just in case short prefix will not be familiar
(there was none such thus far).

> The other advantage of full "pacemaker" is that we can keep the name
> of the master process (pacemakerd) the same. That seems to be a strong
> preference. Otherwise pcmk-initd would be the likely choice for that.

(far less opinionated than in cib case, could also be pcmk-masterd
or something to that effect to honor original sense of "master control
process"; oh I hear, what a blasphemy now with promotable clones, but
historical init systems just accepted the children passed away, this
is rather sort of local-only-HA supervisor of the cluster-resource-HA
constituents, perhaps raising on importance if the count of supervised
processes will grow as sketched recently in two contexts in this
thread)

> I'm still leaning to "pacemaker-", but if there's a strong sentiment
> for "pcmk-", there's still time to switch (though not much, I'm working
> on this now and hope to have rc3 out next week).

With "pcmk-" prefix, there would be just one more thing to solve: what
should "pcmk" executable do (so as to occupy the namespace fully).
It could serve as an old name -> new name translator and, without
parameters, provide the same info as "pacemakerd -F", with switches
reserved for future use :-)

1 Kč

-- 
Poki
-------------- next part --------------
A non-text attachment was scrubbed...
Name: not available
Type: application/pgp-signature
Size: 819 bytes
Desc: not available
URL: <https://lists.clusterlabs.org/pipermail/users/attachments/20180411/6f7b35c8/attachment-0002.sig>