----- Original Message ----- > From: "Lars Marowsky-Bree" <l...@suse.com> > To: "The Pacemaker cluster resource manager" <pacemaker@oss.clusterlabs.org> > Sent: Monday, November 12, 2012 8:24:54 AM > Subject: Re: [Pacemaker] Enable remote monitoring > > On 2012-11-09T17:06:32, David Vossel <dvos...@redhat.com> wrote: > > OK, I should first have read the whole thread. Sorry about that. > Brain > whacko. > > > > It needs to be a new class because the scripts (I'm pretty sure) > > > follow a completely different API to anything else we support. > > Right. That's what I meant, of course. Not what I wrote! ;-) > > > Yep, I'm convinced. Looking what is actually going on to make a > > group, we'd probably break the world if we overloaded it with this > > new > > stuff. Sorry for getting us sidetracked. I just like to start by > > making sure we can't leverage work we've already done before > > talking > > about all this new stuff. > > Ok, so not a group. I'm fine with that. > > I could also imagine this to be a special flag on the ordering > dependency: > > Status quo: order A->B implies B is started after B. If B fails, > nothing > happens with A. > > 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. > > > 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. > > Does the order in which the members of the container start > > monitoring > > matter? Do the members need to be serialized or anything, or can > > we > > just start the container parent, then assume it is okay to start > > all > > the container members? Having the internal constraints only > > interact > > between the parent and children resources makes this less complex. > > Concurrency ought to be safe. But for the cases where this is not > desired, they can chain dependencies anyway. > > (i.e., if they do > "order foo inf: vm1 (a b c) restart-container=true" > versus > "order vm1 a b c") I'd like to avoid having to do this. The order between the vm and the members is already implied by the container abstraction. Having an implied start order for the container's members doesn't seem like a bad idea as well if it is useful. I'd rather not give people the option to build dependencies with container members if we can help it. If we think the start order of members is going to matter, lets go ahead and make that part of the behavior of the container. We'll just say the order in which the members are listed are the order in which they start (similar to a group). If people don't need this logic, having start order in place by default shouldn't cause any problems. For people who want to use it, it will be there for them without having to build any dependency logic themselves. -- Vossel > > Also, how many of these nagios resources do you think will live per > > a container? > > Probably 1-3. > > > 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
