[Pacemaker] Enable remote monitoring

[Dejan Muhamedagic]

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 <lmb at suse.com> wrote:
> > On 2012-11-09T11:04:15, Andrew Beekhof <andrew at 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 at 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 at 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