[Pacemaker] Enable remote monitoring

[David Vossel]

----- Original Message -----
> From: "Lars Marowsky-Bree" <lmb at suse.com>
> To: "The Pacemaker cluster resource manager" <pacemaker at oss.clusterlabs.org>
> Sent: Tuesday, December 4, 2012 11:05:51 AM
> Subject: Re: [Pacemaker] Enable remote monitoring
> 
> On 2012-12-04T11:45:16, David Vossel <dvossel at redhat.com> wrote:
> 
> > I am okay with this constraint option being implemented, as it is
> > the basis for this whole concept.  When it comes time to make this
> > usable, don't make the abstraction people use to configure this
> > relationship live at the crm shell... meaning, Don't introduce the
> > idea of a container object in the shell which then goes off and
> > explodes the constraint section under the hood.  Think this
> > through and come up with a plan to represent what is going on at
> > the configuration level.
> 
> A resource set already is defined in the constraint section, like Yan
> said.
> 
> That seems to do what you ask for? We have the primitives etc defined
> in
> the resources section and then glue them together in the constraints;
> that's as intended. Objects and their relationships.
> 
> Is there something you don't like about Yan's proposal? Sorry for
> asking
> a dumb question, but I can't tell from the above what you'd like to
> see
> changed.

I'm fine with the new order constraint option.

> 
> How would you make this more "usable"?

The resource ordered set with the 'restart-origin' option gets us half way there in the constraint definition.  We still have to build the colocation set between the vm and the resources so everything runs on the same node (perhaps I just assumed that was necessary, correct me if I am wrong)

The above is "usable", but it requires the user to explicitly set up and manage multiple constraint definitions.  It seems to me like we will eventually want to simplify this process.  When that time comes, I just want to make sure we approach building the simplified abstraction at the configuration level and have the management tools (crm/pcs) be a transparent extension of whatever we come up with.

-- Vossel


> 
> Yes, a frontend might decide to render resource sets special (more
> like
> how groups are handled[1]), but I'm not sure I understand what you're
> suggesting.
> 
> 
> Regards,
>     Lars
> 
> [1] and it'd perhaps even be cleaner if, indeed, we had resource sets
> instead of groups, and could reference them as aggregates as well.
> But
> that may be a different discussion.
> 
> --
> 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
>