Tick tock. I'm going to push this soon unless someone raises an objection RSN.
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
