27.07.2011 05:25, Andrew Beekhof wrote: ... >> * 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.
Yep, I actually had clones in mind. > >> * (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. Yes, I understand your point. That's why I marked this as a wish. It would be a killer feature - serialization of clone instances restarts. > >> 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@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 >> > > _______________________________________________ > Pacemaker mailing list: Pacemaker@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 _______________________________________________ Pacemaker mailing list: Pacemaker@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
