[Pacemaker] Reload action and stop/start sequence questions

[Vladislav Bogdanov]

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).
* 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? 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?)
* (wish) Resources should be migrated out of node (if they support live
migration) for stop/start sequence of resource they depend on.
* (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). 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