Hi Andrew, Thanks for the comments! On 12/06/12 09:44, Andrew Beekhof wrote: > > On 05/12/2012, at 11:27 PM, "Gao,Yan" <y...@suse.com> wrote: > >> Hi, >> This is the first step - the support of "restart-origin" for order >> constraint along with the test cases: >> >> https://github.com/gao-yan/pacemaker/commits/restart-origin >> >> It looks straight-forward to me. Hope I didn't miss anything ;-) >> >> If restart-origin="true" combines with kind="Optional", it just means >> "Optional". So that a failed nagios resource would not affect the vm. >> >> I'm not sure if we should relate the restarts count with the >> migration-threshold of the basic resource. Even without this, users can >> specify how many failures of a particular nagios resource they can >> tolerate on a node, the vm will migrate with it anyway. > > Does that make sense though? > You've not achieved anything a restart wouldn't have done. > The choice to move the VM should be up to the VM. If the fail-count of a nagios resource reaches its own migration-threshold, the colocated VM should migrate with it anyway, shouldn't it?
I like the concept of "failure-delegate". If we introduce it, it sounds more like a resource's meta/op attribute to me, rather than into order constraint or group. What do you think? Regards, Gao,Yan -- Gao,Yan <y...@suse.com> Software Engineer China Server Team, SUSE. _______________________________________________ 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://bugs.clusterlabs.org
