On 5/4/2011 at 08:49 PM, Andrew Beekhof <and...@beekhof.net> wrote: > Tick tock. I'm going to push this soon unless someone raises an objection > RSN.
This is going into 1.1, right? Do existing CIBs automagically get updated to this syntax, or does the admin have to force this? (Sorry, I forget if that was covered already). Thanks, Tim > > On Fri, Apr 15, 2011 at 4:55 PM, Andrew Beekhof <and...@beekhof.net> wrote: > > On Fri, Apr 15, 2011 at 3:00 PM, Lars Marowsky-Bree <l...@novell.com> > > wrote: > >> On 2011-04-13T08:37:12, Andrew Beekhof <and...@beekhof.net> wrote: > >> > >>> >> Before: > >>> >> > >>> >> <rsc_colocation id="coloc-set" score="INFINITY"> > >>> >> <resource_set id="coloc-set-0"> > >>> >> <resource_ref id="dummy2"/> > >>> >> <resource_ref id="dummy3"/> > >>> >> </resource_set> > >>> >> <resource_set id="coloc-set-1" sequential="false" > >>> >> role="Master"> > >>> >> <resource_ref id="dummy0"/> > >>> >> <resource_ref id="dummy1"/> > >>> >> </resource_set> > >>> >> </rsc_colocation> > >>> >> <rsc_order id="order-set" score="INFINITY"> > >>> >> <resource_set id="order-set-0" role="Master"> > >>> >> <resource_ref id="dummy0"/> > >>> >> <resource_ref id="dummy1"/> > >>> >> </resource_set> > >>> >> <resource_set id="order-set-1" sequential="false"> > >>> >> <resource_ref id="dummy2"/> > >>> >> <resource_ref id="dummy3"/> > >>> >> </resource_set> > >>> >> </rsc_order> > >>> >> > >>> >> > >>> >> > >>> >> After: > >> > >> So I am understanding this properly - we're getting rid of the > >> "sequential" attribute, yes? > > > > Absolutely. > > > >> If so, three cheers. ;-) > >> > >> Can you share the proposed schema and XSLT, if you already have some? > > > > Attached > > > >> > >>> >> <rsc_colocation id="coloc-set" score="INFINITY"> > >>> >> <colocation_set id="coloc-set-1" internal-colocation="0"> > >>> >> <resource_ref id="dummy0" role="Master"/> > >>> >> <resource_ref id="dummy1" role="Master"/> > >>> >> </colocation_set> > >>> >> <colocation_set id="coloc-set-0" > >>> >> internal-colocation="INFINITY"> > >>> >> <resource_ref id="dummy2"/> > >>> >> <resource_ref id="dummy3"/> > >>> >> </colocation_set> > >>> >> </rsc_colocation> > >>> >> <rsc_order id="order-set" kind="Mandatory"> > >>> >> <ordering_set id="order-set-0" internal-ordering="Mandatory"> > >> > >> So we have "(score|kind)" on the outside, and > >> "internal-(ordering|colocation)" on the inner elements. Is there a > >> particular reason to use a different name on the inner ones? > > > > The language didn't feel right tbh - the inner ones felt like they > > needed more context/clarification. > > We can change the outer name too if you like. > > > >> Also, rsc_order has either score or kind; are you doing away with that > >> here? > > > > Yes. Standardizing on "kind". Score never made sense for ordering :-( > > > >> > >> "lifetime" would only apply to the entire element, right? > > > > right > > > >> And, just to be fully annoying - is there a real benefit to having > >> ordering_set and colocation_set? > > > > Very much so. Because kind makes no sense for a colocation - and > > vice-versa for score. > > Using different element names means the rng can be stricter. > > > >> > >> > >>> >> <ordering_set id="order-set-1" internal-ordering="Optional"> > >>> >> <resource_ref id="dummy2"/> > >> > >> While we're messing with sets anyway, I'd like to re-hash the idea I > >> brought up on pcmk-devel. To make configuration more compact, I'd like > >> to have "automatic sets" - i.e., the set of all resources that match > >> something. > >> > >> Imagine: > >> > >> <resource_list type="Xen" provider="heartbeat" class="ocf" /> > >> > >> and suddenly all your Xen guests are correctly ordered and collocated. > >> The savings in administrative complexity and CIB size are huge. > >> > >> Or would you rather do this via templates? > > > > You mean something like? > > > > <ordering_set id="order-set-0" internal-ordering="Mandatory"> > > <resource_pattern type= provider= > > > </ordering> > > > > Might make sense. But doesn't strictly need to be bundled with this > change. > > I'd be wary about allowing pattern matching on the name, I can imagine > > resources ending up in multiple sets (loops!) very easily. > > > > _______________________________________________ > 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://developerbugs.linux-foundation.org/enter_bug.cgi?product=Pacemaker > -- Tim Serong <tser...@novell.com> Senior Clustering Engineer, OPS Engineering, Novell Inc. _______________________________________________ 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://developerbugs.linux-foundation.org/enter_bug.cgi?product=Pacemaker
