Have you ever changed a resource agent in a backward-incompatible way, and found yourself wishing you could do a rolling upgrade?
With a new feature in the current master branch, which will be part of the next Pacemaker release, you will be able to specify different resource parameters to be used with different versions of a resource agent. Pacemaker already supports using rules to select resource parameters. You can, for example, use different parameters on different nodes, or at different times of the day: http://clusterlabs.org/doc/en-US/Pacemaker/1.1-pcs/html-single/Pacemaker_Explained/index.html#_using_rules_to_control_resource_options The new feature allows the special node attribute #ra-version in these rules (comparable to the built-in #uname for node name). When a resource has a rule with #ra-version, Pacemaker will evaluate the rule against the installed version of the resource agent, as defined by <resource-agent ... version=... > in the agent's metadata. For example, the following XML configuration creates a resource "A", and passes the options "widget=1 really-old-param=5" if the resource agent version is 1.0 or older, and the options "widget=1 super-new-param=10" if the version is newer: <primitive id="A" class="ocf" provider="me" type="myRA"> <instance_attributes id="id01" score="3"> <rule id="id02" score="INFINITY" > <expression id="id03" type=version attribute="#ra-version" operation="gt" value="1.0"/> </rule> <nvpair id="id04" name="super-new-param" value="10"/> </instance_attributes> <instance_attributes id="id05" score="2"> <rule id="id06" score="INFINITY" > <expression id="id07" type=version attribute="#ra-version" operation="lte" value="1.0"/> </rule> <nvpair id="id08" name="really-old-param" value="5"/> </instance_attributes> <instance_attributes id="id09" score="1"> <nvpair id="id10" name="widget" value="1"/> </instance_attributes> </primitive> Of course, higher-level tools may provide a more convenient interface. This allows for a rolling upgrade of a resource agent that changed parameters. Some nodes can have the older version, and others can have the newer version, and the correct parameters will be used wherever the resource is placed. Some considerations before using: * All nodes must be upgraded to a Pacemaker version supporting this feature before it can be used. * The version is re-checked whenever the resource is started. A stop action is always executed with the same parameters as the previous start. Therefore, it is still not recommended to upgrade a resource agent while the resource is active on that node -- each node should be put into standby when it is upgraded (or if only the resource agent is being upgraded, ensure the resource is not running on the node). * The version check requires an extra metadata call when starting the resource. * Live (hot) migration is disabled when versioned parameters are in use (otherwise, half the migration could be performed with one set of parameters and the other half with another set). The impact of the last two points can be minimized by using versioned parameters only while upgrades are being done, and using normal (unversioned) parameters otherwise. Special thanks to Igor Tsiglyar and Mikhail Ksenofontov, who created this feature as part of a student project with EMC under the supervision of Victoria Cherkalova. -- Ken Gaillot <kgail...@redhat.com> _______________________________________________ Users mailing list: Users@clusterlabs.org http://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
