[ClusterLabs] Antw: 2017 ClusterLabs Summit -- Pacemaker 1.2.0 or 2.0 talk

[Ulrich Windl]

>>> Ken Gaillot <kgaillot at redhat.com> schrieb am 06.09.2017 um 18:38 in Nachricht
<1504715919.4926.25.camel at redhat.com>:
> I thought the first day of the 2017 ClusterLabs Summit went impressively
> well today. We had about 50 attendees from Alteeve, Citrix, Debian,
> Linbit, Red Hat, SuSE, and possibly more I've missed. The talks were
> packed with information and covered a wide variety of topics, from
> container orchestration to storage management to GUIs.
> 
> I gave a talk on future directions for Pacemaker. The slides are
> available at:
> 
>    https://www.clusterlabs.org/images/Pacemaker-slides-2017-09-06.pdf 
> 
> The main idea is that Pacemaker 1.2.0 and/or 2.0 will be more about
> removing legacy code more than adding anything new. As the slides are
> presented, my original idea was to release 1.2.0 in the near term, with
> smaller changes that don't affect rolling upgrades, then 2.0 at some
> point further in the future, that would break rolling upgrades for a
> (hopefully small) subset of users.
> 
> However after discussions during and after the talk, it seems more
> worthwhile to go straight to 2.0, with the major change being dropping
> support for the legacy cluster layers -- heartbeat, CMAN, and the
> corosync 1 pacemaker plugin. This would allow us to simplify the
> pacemaker code and make it easier to add new features in the future. We
> would keep the 1.1 branch alive for a period of time, and anyone who
> still uses the older stacks, but is interested in fixes or features from
> the 2.0 line, could submit pull requests to backport them to 1.1.
> 
> I'd like to open the discussion on this list as to what changes should
> be in 2.0. The slides give some examples that fall into categories:
> 
> * Changes in Pacemaker's defaults: a higher default stonith-timeout;
> defaulting record-pending to true, which will allow status displays to
> show when an action (such as start or stop) is currently in progress;
> interpreting a negative stonith-watchdog-timeout as meaning to
> automatically calculate a value (the default of 0 would continue to mean
> disabling watchdog use by Pacemaker); moving the default location of the
> Pacemaker detail log to /var/log/cluster/pacemaker.log (a change from
> the slides, based on summit discussions), and removing support for some
> very rarely used legacy names for various configuration values.

I'd vote for trying to trim the extraordinary long lines that only pacemaker seems to add to syslog. Usually I'll have to pull my terminal as wide as the screen allows to see the lines in a reasonable format...

> 
> * Changes in command-line tool behavior: We might drop old legacy
> synonyms for command-line options, such as "crm_resource --host-uname"
> for what is now "crm_resource --node"; and remove crm_mon's built-in
> SNMP/ESMTP support in favor of the relatively recent alerts feature.

Talking of obsolete options: PLEASE make sbd treat options in a reasonable way instead of using options like "-1" "-2", etc.

> 
> * Changes in the C API: This would affect very few people -- only users
> who wrote their own C code using the Pacemaker C libraries. We would
> coordinate these changes with the handful of public projects (such as
> sbd) that use the API. These changes will be discussed further on the
> developers at clusterlabs.org mailing list rather than this one.
> 
> * Breaking rolling upgrades for certain legacy features: We would try to
> keep the number of affected users to a minimum. Examples are
> configurations created under pre-Pacemaker-1.0 and never converted to
> the post-1.0 XML syntax; the undocumented "resource isolation" feature,
> which has been superseded by the new bundle feature; certain legacy
> cluster options that changed names long ago; and as mentioned, support
> for the heartbeat, CMAN, and corosync 1+plugin stacks. Also, dropping
> support for "legacy attrd" would mean that rolling upgrades from
> Pacemaker older than 1.1.11, even if running on corosync 2, would not
> work (even then, a rolling upgrade would work in two steps, first to a
> later 1.1 version, then to 2.0).

Hmm: "crm configure upgrade" ;-)

> 
> The purpose of this email is to start a discussion about these changes.
> Nothing is set in stone. We do want to focus more on removing legacy
> usage rather than adding new features in the 2.0 release. Anyone who has
> an opinion or questions about the changes mentioned above, or
> suggestions for similar changes, is encouraged to participate.

Regards,
Ulrich