On Fri, Dec 7, 2012 at 3:00 PM, Gao,Yan <y...@suse.com> wrote: > On 12/07/12 07:38, Andrew Beekhof wrote: >> >> On 06/12/2012, at 10:42 PM, Lars Marowsky-Bree <l...@suse.com> wrote: >> >>> On 2012-12-06T22:25:40, Andrew Beekhof <and...@beekhof.net> wrote: >>> >>>> But any failures of the nagios agents would count against the VM's >>>> migration-threshold. >>>> So if moving were the right thing to do, it would have done it already. >>> >>> OK. I think this was due to me still being stuck on the workings of an >>> order constraint, but of course if the failures are instead attributed >>> to the container, this would happen automatically already. True. >>> >>> (Incidentally, I like "attribute", "ascribe" better than "delegate" >>> because to me, they better fit what's going on, if we sticked with >>> "delegate-failures". Just saying. ;-) >> >> My use of "delegate" comes from my time with ObjectiveC where its common >> practice to use them for "I'm not going to handle X but here is something >> that does" style functionality. >> Which fits nicely with what we're doing here. >> >> container="vm" also works though. >> >>> >>>>> We already have on-fail settings. How would these play together? >>>> Good question. My initial thought was that it would be up to on-fail >>>> settings in the VM. >>> >>> I'd prefer to keep that separate (as proposed below). Because if an >>> action of the *VM* really fails, I may want an admin to look into it >>> (why could the bloody hypervisor not start/stop it?), which is different >>> from restarting the VM if one of the resources within it needs that. >>> >>>>> Would it even make sense to have on-fail="restart-container"? (Or a >>>>> nicer wording.) >>>>> >>>>> Hmmm. That might work. We allow a "container" to be specified as a meta >>>>> attribute. >>>>> >>>>> If set, on-fail would default to restart container for most actions. But >>>>> admins could actually modify it - say, they might want to set >>>>> monitor on-fail="ignore" to just get notified. And when we move forward >>>>> to whiteboxes, we could have start/monitor/promote/demote >>>>> on-fail="restart" (like now) and stop on-fail="restart-container". >>>>> >>>>> That appears reasonably neat? >>>> It does actually. >>>> I wasn't originally thinking it was necessary but it makes sense now >>>> that you point it out. >>> >>> Yes, I think I like this too now. >>> >>> Uhm. Would "container" imply ordering + colocation, or would we still >>> need them grouped (resource_set'ed, whatever)? >> >> Ordering: absolutely > Would any user not like the implied order? Instead want an asymmetrical > or some curious one?
Conceptually it doesn't make any sense IMHO. By definition things cant be in/on the container if the container doesn't exist yet. The one thing we've not addressed yet is probing, thats going to be fun :) > Although it seems just putting a mandatory > "container:start -> resource:start" internally should applies for most > cases, and it would simplify the configuration of the "white" container. > > Regards, > Gao,Yan > > >> Colocation is less clear, I think the default is no but David has suggested >> an additional meta attribute to turn it on. >> >> > > -- > 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
