On Fri, Mar 30, 2012 at 7:34 PM, Florian Haas <flor...@hastexo.com> wrote: > On Fri, Mar 30, 2012 at 1:12 AM, Andrew Beekhof <and...@beekhof.net> wrote: >> Because it was felt that RAs shouldn't need to know. >> Those options change pacemaker's behaviour, not the RAs. >> >> But subsequently, in lf#2391, you convinced us to add notify since it >> allowed the drbd agent to error out if they were not turned on. > > Yes, and for ordered the motivation is exactly the same. Let me give a > bit of background info. > > I'm currently working on an RA for GlusterFS volumes (the server-side > stuff, everything client side is already covered in > ocf:heartbeat:Filesystem). GlusterFS volumes are composed of "bricks", > and for every brick there's a separate process to be managed on each > cluster node. When these brick processes fail, GlusterFS has no > built-in way to recover, and that's where Pacemaker can be helpful. > > Obviously, you would run that RA as a clone, on however many nodes > constitute your GlusterFS storage cluster. > > Now, while brick daemons can be _monitored_ individually, they can > only be _started_ as part of the volume, with the "gluster volume > start" command. And if we "start" a volume simultaneously on multiple > nodes, GlusterFS just produces an error on all but one of them, and > that error is also a generic one and not discernible from other errors > by exit code (yes, you may rant). > > So, whenever we need to start >1 clone instance, we run into this problem: > > 1. Check whether brick is already running. > 2. No, it's not. Start volume (this leaves other bricks untouched, but > fires up the brick daemons expected to run locally). > 3. Grumble. A different node just did the same thing. > 4. All but one fail on start. > > Yes, all this isn't necessarily wonderful design (the start volume > command could block until volume operations have completed on other > servers, or it could error out with a "try again" error, or it could > sleep randomly before retrying, or something else), but as it happens > configuring the clone as ordered makes all of this evaporate. > > And it simply would be nice to be able to check whether clone ordering > is enabled, during validate. > >> I'd need more information. The RA shouldn't need to care I would have >> thought. The ordering happens in the PE/crmd, the RA should just do >> what its told. > > Quite frankly, I don't quite get this segregation of "meta attributes > we expect to be relevant to the RA"
The number of which is supposed to be zero. I'm not sure "cutting down on questions to the mailing list" is a good enough reason for adding additional exceptions. The one truly valid exception in my mind is globally-unique, since the monitor operation has to work quite differently. My concern with providing them all to RAs is that someone will probably start abusing them. Like target-rc has been in the past - one agent actually returned it in the monitor op. > and "meta attributes the RA > shouldn't care about." Can't we just have a rule that _all_ meta > attributes, like parameters, are just always available in the RA > environment with the OCF_RESKEY_CRM_meta_ prefix? > > Cheers, > Florian > > -- > Need help with High Availability? > http://www.hastexo.com/now > > _______________________________________________ > 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
