On 12/07/12 12:09, Andrew Beekhof wrote: > 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. Right.
> > The one thing we've not addressed yet is probing, thats going to be fun :) I guess there should be some way for the nagios RAs to return NOT_RUNNING if there's nothing yet, no? 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
