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. > 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. > > > 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
