----- 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. I'm just not sure about the symmetrical=false use case for order constraints. > > 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. If we are talking about counting the restarts of the vm towards the migration-threshold, 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. > 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. -- Vossel > > > On 12/05/12 06:05, Lars Marowsky-Bree wrote: > > On 2012-12-04T14:48:50, David Vossel <dvos...@redhat.com> wrote: > > > >> The resource ordered set with the 'restart-origin' option gets us > >> half way there in the constraint definition. We still have to > >> build the colocation set between the vm and the resources so > >> everything runs on the same node (perhaps I just assumed that was > >> necessary, correct me if I am wrong) > > > > Right, we end up with two resource sets. > > > > (Unless we allow the "restart-origin" to be set for the order > > constraints that are implicit if a colocation resource set is used > > with > > sequential=true. Ouch.) > Ouch > > > > > > >> The above is "usable", but it requires the user to explicitly set > >> up > >> and manage multiple constraint definitions. It seems to me like > >> we > >> will eventually want to simplify this process. When that time > >> comes, > >> I just want to make sure we approach building the simplified > >> abstraction at the configuration level and have the management > >> tools > >> (crm/pcs) be a transparent extension of whatever we come up with. > > > > For what it is worth, I'd agree with this; the fact that the most > > common > > constraints are order *AND* colocation and we don't have a > > (link|chain|join) statement that adequately provides that has been > > annoying me for a while. ;-) I massively appreciate that we do have > > the > > separate dimensions, and people use that - but still, the > > combination of > > both is extremely common. > > > > The independent order + colocation statements do allow for that > > though; > > and in theory, a frontend *could* detect that there's both "A > > first, > > then B" and "B where A is" with the same priority and present it > > merged > > as: > > > > join id-494 inf: A B > Looks neat :-) > > 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
