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

[Ken Gaillot]

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.

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

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

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.

-- 
Ken Gaillot <kgaillot at redhat.com>