On Sat, Nov 10, 2012 at 08:39:42AM +1100, Andrew Beekhof wrote: > On Fri, Nov 9, 2012 at 10:25 PM, Lars Marowsky-Bree <l...@suse.com> wrote: > > On 2012-11-09T11:04:15, Andrew Beekhof <and...@beekhof.net> wrote: > > > >> So I was just explaining the problem and context to David... his > >> comment was "aren't these just unmanaged resources and some > >> constraints?". > > > > They can even be managed - the start would be a "while ! monitor ; sleep > > 1 ; done" fake, and similar for stop. And then you could see the > > services wink in and out too. > > ack > > > > >> Of course its slightly more complex than that, but what if we made a > >> "container" type in the PE? > >> Something analogous to groups (ie. a parent with N children) but > >> possibly without the internal ordering. > > > > Yes. We thought about a new meta attribute to a group too. > > > >> Conceptually its also a little closer to how the admin probably thinks > >> of the system and we'd make the semantics be that you don't start > >> monitoring the children until the parent is fully up and any failures > >> are a failure of the parent (optional?). > > > > Right, the last bit is the interesting one. Basically, an ordering > > dependency which works the other way around for "monitor" than it works > > for start/stop, and that could be turned on for the group via the > > special attribute. > > > > There is one downside that I've not yet been able to circumvent: > > templates. The monitor op would have allowed one to write something > > like: > > > > rsc_template vm-web ocf:heartbeat:VirtualDomain ... \ > > op monitor nagios:http ... > > > > With the container syntax, this will look like: > > > > primitive vm-web-1 ocf:heartbeat:VirtualDomain ... > > primitive vm-web-1-monitor nagios:http ... > > group container-vm-web-1 vm-web-1 vm-web-1-monitor \ > > meta container="vm-web-1" > > > > For each VM. i.e., the CIB would blow up considerably more. But that > > might be acceptable and solved later ...? > > Well you can still use templates for and within the container. > Its also possible for shells and GUIs to hide some of the > configuration and status details if they like. > You can represent it any way you like, it doesn't have to match the > XML object-for-object.
There's also one aspect which we didn't consider (or I missed it). The new "container" element cannot be part of a group, whereas if the monitor op is extended there wouldn't be such a constraint. Thanks, Dejan > > > > Regards, > > Lars > > > > PS: any UI tool could render "group ... meta container='vm-web-1'" as > > "container ..." directly, too. Just thinking this might make the XML > > neater. > > > > -- > > 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 _______________________________________________ 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