----- Original Message ----- > From: "Lars Marowsky-Bree" <l...@suse.com> > To: "The Pacemaker cluster resource manager" <pacemaker@oss.clusterlabs.org> > Sent: Monday, November 12, 2012 1:16:49 PM > Subject: Re: [Pacemaker] Enable remote monitoring > > On 2012-11-12T14:03:24, David Vossel <dvos...@redhat.com> wrote: > > > > We want "A" to be restarted if "B" fails. (If A->B are also > > > collocated, we'd also get fail-over after migration-threshold > > > triggers. That may not always be desired.) > > I'm not sure I follow why we'd be concerned about > > migration-threshold > > here. The only situation I can think of were migration-threshold > > could cause weird behavior is if someone sets a migration threshold > > on > > the children but not on the parent, but that seems like a > > configuration problem to me. > > I was saying that we don't need to concern ourselves about them, > actually. > > If rsc-vm1 and vm1-http are collocated (in addition to being ordered > with the magic flag), the Nth failure of the web service will trigger > the rsc-vm1 to be moved along with vm1-http, which is desired. > > > > A "restart-origin" attribute, perhaps? > > Would this attribute need to be exposed through the configuration? > > > > I was thinking this constraint would be an implied relationship > > between the container parent and members internally. We probably > > already have the right set of flags internally in the pengine to > > represent this sort of constraint. If we don't need to expose this > > logic to the config my vote is to limit it to the container use > > case > > for now. > > I was thinking that the constraint - either as a flag to the order > constraint or a new one - *would* be the configuration syntax. > > I don't so much like a new container object. That was one of the > things > that were wrong with "groups", design-wise. The > grouping/relationships > of objects belong into the constraints section. > > A new attribute to the order constraint is also fully and completely > backwards compatible with any and all tools we're using today.
Yes, introducing the new order constraint attribute would allow all this to be possible without the container object, but all the dependencies between the vm and the children would have to be generated in the constraint section (order and colocation constraints). I'm not sure how I feel about that. It is easier from an implementation standpoint, but puts a larger burden on the user. Perhaps we introduce the order constraint attribute and the new lrmd work so remote monitoring will be technically possible (large configuration burden though). Then we approach the container object as a syntactic shortcut similar to the group object later on if we want to. -- Vossel > A container object means that we need to teach each and every tool > about > them again; that one can reference the primitives they contain in > dependencies, etc. > > > Regards, > Lars > > -- > Architect Storage/HA > SUSE LINUX Products GmbH, GF: Jeff Hawn, Jennifer Guild, Felix > Imendörffer, HRB 21284 (AG Nürnberg) > "Experience is the name everyone gives to their mistakes." -- Oscar > Wilde > > > _______________________________________________ > 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
