[Pacemaker] Reload action and stop/start sequence questions

[Andrew Beekhof]

On Mon, Jul 11, 2011 at 5:45 PM, Vladislav Bogdanov
<bubble at hoster-ok.com> wrote:
> Hi all,
>
> Would somebody (Andrew?) please bring some light on how exactly
> redefinition of resource is supposed to be handled?
>
> Below is my (rather perfectionistic) vision on this, please correct me
> if/where I'm wrong:
> * If RA supports 'reload' action then it is called on resource
> definition change (instead of stop/start).

Only if the attribute changed was NOT marked as "unique" in the metadata.

> * If 'reload' action fails then usual start/stop sequence is executed.
> This would give a chance to RA to refuse to reload if some key
> properties change, while allowing it to tune some secondary resource
> parameters. Of course, RA should leave resource in a usable state, so
> failure of reload action should indicate RA's denial to do a reload. How
> to differentiate that from real reload failures?

Either way the resource needs to be restarted.  So there is no need
for differentiation.

> Is there some special
> exit code for that?
> * Dependent resources should not be stopped/started for 'reload' action.
> Of course they are restarted if reload fails and stop/start is executed
> then. (I see that they are restarted now for reload of a resource they
> depend on, is it a bug?)

More like a limitation.  Which is a round-a-bout way of saying "really
hard to fix bug".
You're welcome to create a BZ for it though, maybe one day I'll figure
out how to resolve it.

> * (wish) Resources should be migrated out of node (if they support live
> migration) for stop/start sequence of resource they depend on.

Migration can only occur if a resource at the bottom (excluding any
clones) of the resource stack.
In order to migrate any colocation dependancies need to be running at
_both_ the old and the new locations.

This can only be true for resources that depend on clones.

> * (wish) Redefinition of clones should be handled in a way which allows
> dependent live-migratable resources to survive (if reload action for
> clone instance either is not supported or fails).

This doesn't make sense.
If the definition of one clone changes, then they all change and there
is nowhere for dependant resources to migrate to.

> That is: dependent
> resources which support live migration are first tried to migrate out of
> one node, and are stopped if migration fails. Then clone instance is
> restarted on that node. Then the same procedure applies to next cluster
> node so resources may return back to a first node.
>
> If above (at least first three points) is right, then is it possible to
> get a set of previous instance parameters the same way new configuration
> is passed (env vars), or RA should save that information itself in advance?
>
> Best,
> Vladislav
>
> _______________________________________________
> Pacemaker mailing list: Pacemaker at oss.clusterlabs.org
> http://oss.clusterlabs.org/mailman/listinfo/pacemaker
>
> Project Home: http://www.clusterlabs.org
> Getting started: http://www.clusterlabs.org/doc/Cluster_from_Scratch.pdf
> Bugs: http://developerbugs.linux-foundation.org/enter_bug.cgi?product=Pacemaker
>