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 develop...@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 <kgail...@redhat.com> _______________________________________________ Users mailing list: Users@clusterlabs.org http://lists.clusterlabs.org/mailman/listinfo/users Project Home: http://www.clusterlabs.org Getting started: http://www.clusterlabs.org/doc/Cluster_from_Scratch.pdf Bugs: http://bugs.clusterlabs.org