[ClusterLabs] Coming in 1.1.16: versioned resource parameters

[Ken Gaillot]

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 <kgaillot at redhat.com>