On Wed, Jan 18, 2012 at 6:00 AM, Dejan Muhamedagic <deja...@fastmail.fm> wrote: > Hello, > > On Tue, Jan 03, 2012 at 05:19:14PM +1100, Andrew Beekhof wrote: >> Does anyone have an opinion on the following schema and example? >> I'm not a huge fan of the index field, but nor am I of making it >> sensitive to order (like groups). > > What is wrong with order in XML elements? It seems like a very > clear way to express order to me.
Because we end up with the same update issues as for groups. > >> Please keep in mind that the new topology section is optional and >> would only be defined if: >> - you wanted to specify the order in which multiple devices were tried, or >> - if multiple devices need to be triggered for the node to be >> considered fenced. > > Triggered serially I guess? Yes. > Is there a possibility to express > fencing nodes simultaneously? No. Its regular boolean shortcut semantics. >> Most people will /NOT/ need to add this section to their configuration. >> >> -- Andrew >> >> <fencing-topology> >> <!-- pcmk-0 requires the devices named disk + network to complete --> >> <fencing-rule id="f-p0" node="pcmk-0"> >> <device id-ref="disk"/> >> <device id-ref="network"/> >> </fencing-rule> >> >> <!-- pcmk-1 needs either the poison-pill or power device to complete >> successfully --> >> <fencing-rule id="f-p1.1" node="pcmk-1" index="1" device="poison-pill"/> >> <fencing-rule id="f-p1.2" node="pcmk-1" index="2" device="power"> >> >> <!-- pcmk-1 needs either the disk and network devices to complete >> successfully OR the device named power --> >> <fencing-rule id="f-p2.1" node="pcmk-2" index="1"> >> <device id-ref="disk"/> >> <device id-ref="network"/> >> </fencing-rule> >> <fencing-rule id="f-p2.2" node="pcmk-2" index="2" device="power"/> >> >> </fencing-topology> >> >> Conforming to: >> >> <define name="element-stonith"> >> <element name="fencing-topology"> >> <zeroOrMore> >> <ref name="element-fencing"/> >> </zeroOrMore> >> </element> >> </define> >> >> <define name="element-fencing"> >> <element name="fencing-rule"> >> <attribute name="id"><data type="ID"/></attribute> >> <attribute name="node"><text/></attribute> >> <attribute name="index"><text/></attribute> >> <choice> >> <attribute name="device"><text/></attribute> >> <zeroOrMore> >> <element name="device"> >> <attribute name="id-ref"><data type="IDREF"/></attribute> >> </element> >> </zeroOrMore> >> </choice> >> </element> >> </define> > > I'd rather use "stonith-resource" than "device", because what is > referenced is a stonith resource (one device may be used in more > than one stonith resource). Can you rephrase that? I don't follow. Are you talking about a group of fencing devices? > Or "stonith-rsc" if you're in the > shortcuts mood. Or perhaps even "agent". > > "fencing-rule" for whatever reason doesn't sound just right, but > I have no alternative suggestion. Agreed. > > IMO, as I already said earlier, index is superfluous. > > It could also be helpful to consider multiple nodes in a single > element. > > Otherwise, looks fine to me. > > Thanks, > > Dejan > >> </grammar> >> >> _______________________________________________ >> 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 _______________________________________________ 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
