[ClusterLabs] Coming in Pacemaker 2.1.0 (!)

Ken Gaillot kgaillot at redhat.com
Thu Oct 1 18:45:34 EDT 2020


Hi all,

Soon, the first release candidate for Pacemaker 2.0.5 will come out,
with final release expected by the end of the year. Chris Lumens will
coordinate the 2.0.5 release, so look for announcements from him soon.

Beyond that, we are planning a 2.1.0 release in the first half of next
year. It's hard to believe, but it's been more than 2 years since the
release of Pacemaker 2.0.0!

A minor-version bump preserves rolling upgrades (and in this case, C
API compatibility as well) but draws attention to more significant
changes than usual. I've collected the potential changes here:

   https://wiki.clusterlabs.org/wiki/Pacemaker_2.1_Changes

Feedback is welcome. Some of the most notable:

* Pacemaker would drop support for Python 2, which is now end-of-life.
(Pacemaker only uses Python for test scripts and the fence_legacy
wrapper for heartbeat-style fence agents.)

* The concurrent-fencing option would default to true instead of false.

* We would remove the clustermon.sh script that was used before
Pacemaker 1.1.15 to do what alerts do now.

* crm_mon's --simple-status/-s option (generating nagios plugin-style
output) would be deprecated with no replacement. Users would be
recommended to use a nagios community-supplied plugin instead.

* Our documentation set would transition from Publican (a dead project
being dropped by some distributions) to Sphinx. The Sphinx
documentation will actually be available as an option in the 2.0.5
release (and likely used for the documents available online at
clusterlabs.org), then we will drop Publican and use only Sphinx as of
2.1.0.

* We would complete the transition away from master/slave terminology
that was started with 2.0.0. I suggest using "promoted" instead of
"master", and "unpromoted" instead of "slave". Other suggestions are
welcome before we make a final decision. The configuration would
continue to accept the old names for backward compatibility, but only
the new names would be referenced in documentation, logs, and status
output.

We will not break rolling upgrades or C API compatibility in 2.1.0, so
there would be no need to keep the 2.0 series alive with backports.
-- 
Ken Gaillot <kgaillot at redhat.com>








More information about the Users mailing list