[ClusterLabs] Antw: Coming in 1.1.16: versioned resource parameters

[Ulrich Windl]

>>> Ken Gaillot <kgaillot at redhat.com> schrieb am 10.08.2016 um 22:36 in Nachricht
<804dd911-56a6-328c-00a4-43133f59d39f at redhat.com>:
> Have you ever changed a resource agent in a backward-incompatible way,
> and found yourself wishing you could do a rolling upgrade?

Hi!

It seems you are fighting the consequence, not the cause: Why do such a thing? Why not make an intermediate RA that complains about the old parameters being obsolete (BTW: Does the XML metadata have an "obsolete" attribute for parameters?) while also supporting the new parameters? Then you would first update your RAs, the the configuration. Everything will continue to work. Then you can make the next generation of RAs that drop support of the obsolete parameters.

I'm afarid adding more and more features to pacemaker will make it bloatware, instead of being small, efficient and reliable.

Regards,
Ulrich

> 
> 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_Explai 
> ned/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>
> 
> _______________________________________________
> Users mailing list: Users at 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