On 06/12/2012, at 5:00 AM, "Gao,Yan" <y...@suse.com> wrote:
> On 12/06/12 00:36, David Vossel wrote: >> >> >> ----- Original Message ----- >>> From: "Yan Gao" <y...@suse.com> >>> To: pacemaker@oss.clusterlabs.org >>> Sent: Wednesday, December 5, 2012 6:27:05 AM >>> Subject: Re: [Pacemaker] Enable remote monitoring >>> >>> 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 ;-) >> >> I had made some in-line comments for you in git-hub. It looks like you are >> on the right track. > Thanks! > >> I'm just not sure about the symmetrical=false use case for order constraints. > A "symmetrical=false" implies we don't care about the inverse order. > AFAICS, we shouldn't still restart the origin for this case. symmetrical=false makes no sense here. If we stay with the restart-origin approach, then is should override symmetrical=false. > >> >>> >>> If restart-origin="true" combines with kind="Optional", it just means >>> "Optional". So that a failed nagios resource would not affect the vm. >> >> I agree, restart-origin is a no-op for advisory ordering. >> >>> >>> I'm not sure if we should relate the restarts count with the >>> migration-threshold of the basic resource. >> >> I don't know what the "basic resource" refers to here. > The "origin". > >> If we are talking about counting the restarts of the vm towards the >> migration-threshold, > Yep > >> I'd expect the vm to have the same behavior as whatever happens to 'B' right >> now for the use-case below. >> >> Start A then Start B. When A fails restart B. >> >> Start vm then Start nagios. When nagios fails restart vm. > Sure, we have the behaviors with the code. I think we are talking about > the failure count of the VM should only affected by its own monitor, or > also by the resources within it. > >> >> >>> 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. >>> And probably we >>> could have one of the nagios resources, no matter how many times it >>> fails, we just don't want the vm to migrate because of it. >> >> I don't understand this last sentence. > If we didn't set a migration-threshold for a nagios resource, that means > we could always allow it to recover on a node if possible. > > BTW, >> I believe we usually put new options into the 1.2.rng to settle for a >> bit before promoting them into the 1.1 scheme. > We changed the rule? No, David has it backwards :) > We used to put them in 1.1 first and promote into > 1.2 later when I did the other features. AFAIK, validate-with is > initially set to "pacemaker-1.2", which means users would get the > feature immediately, no? > > 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 _______________________________________________ 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
