[Pacemaker] Enable remote monitoring

[Andrew Beekhof]

On 05/12/2012, at 3:45 AM, David Vossel <dvossel at redhat.com> wrote:

> ----- 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 6:59:08 AM
>> Subject: Re: [Pacemaker] Enable remote monitoring
>> 
>> On 2012-12-04T19:48:18, "Gao,Yan" <ygao at suse.com> wrote:
>> 
>>>> Yes, I think this looks good.
>>> The patch to the schema I proposed supports this already ;-)
>> 
>> So it seems that nobody had any serious objections to this approach,
>> but
>> we were fiddling with details and can't actually decide what we like
>> better, if anything. ;-) So why don't we proceed with the initial
>> suggestion for now implement it ("restart-origin" attribute on order
>> constraint), play with it for 1-2 months and fine tune it in
>> practice?
>> 
>> Andrew, David, any objections to that?
> 
> The main thing I want to avoid is an explosion of order and colocation constraints in the configuration to support this functionality.  Pushing this off to configuration management tools like crmsh and psd may help people avoid configuration mistakes, but when it comes to actually debugging what's going on, having a huge constraint section in the config is a nightmare.  Using concepts like groups and sets make these relationships more obvious.  I would really like us to move forward with some sort of abstraction that allows the relationship between the virtual machine and resources within it to be defined as simple as possible.
> 
> 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.  

Personally, I'm ok with the shell exploding things.  A 1-1 mapping between XML and crmsh isn't strictly necessary.
My original motivations for the container concept were two-fold
1) obviousness to the user
2) implementation flexibility for developers

If we expose a new constraint or resource option, then 2. goes out the window and 1. doesn't strictly need to be done at the XML level anymore.

There was also 3) Limited scope for misuse :)
But I'm reasonably confident with 'failure-delegate' on that front.

> Think this through and come up with a plan to represent what is going on at the configuration level.
> 
> -- Vossel
> 
> 
> 
>> 
>> 
>> Regards,
>>    Lars
>> 
>> --
>> 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