On Thu, Jan 19, 2012 at 12:15 AM, Dejan Muhamedagic <deja...@fastmail.fm> wrote: > On Wed, Jan 18, 2012 at 06:58:20PM +1100, Andrew Beekhof wrote: >> 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. > > OK. > > [...] > >> > Is there a possibility to express >> > fencing nodes simultaneously? >> >> No. Its regular boolean shortcut semantics. > > As digimer mentioned, it is one common use case, i.e. for hosts > with multiple power supplies. So far, we recommended lights-out > devices for such hardware configurations and if those are > monitored and more or less reliable such a setup should be fine. > It would still be good to have a way to express it if some day > somebody actually implements it. I guess that the schema can be > easily extended by adding a "simultaneous" attribute to the > "fencing-rule" element.
So in the example below, you'd want the ability to not just trigger the 'disk' and 'network' devices, but the ability to trigger them at the same time? > >> >> 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? > > No, just about naming. The element/attribute name "device" > doesn't seem right to me, because it references a stonith > resource. One (physical) device may be used by more than one > stonith resource. Even though "device" certainly sounds nicer, > it isn't precise. Oh, I see what you mean. I'll see what I can come up with. > What I'm worried about is that it may be > confusing (and we have enough confusion with stonith). > (Or did I completely misunderstand the meaning of "device"?) > > Thanks, > > Dejan > >> > 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 > > _______________________________________________ > 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
