[Linux-ha-dev] Re: crm dtd changes
lmb at suse.de
Wed Jul 7 01:25:14 MDT 2004
Andrew <lists at beekhof.homeip.net> said:
> >>>RA versions now, and have several (class, type, version) entries in
> >>>the metadata section here.
> >>So (class, type, version) are the primary keys for this section?
> >>Ie. all must be specified to return a value?
> >Yes. Keep in mind it's mostly informational to the GUI, we don't much
> >use it ourselves. (or do we?)
> My understanding of where we left all that is that we rely on a fully
> filled out resource entry and therefor dont use that section.
> >Uhm, well, yeah, but why would we set that attribute at all? Either the
> >STONITH operation shows up in the transition graph or it does not; why
> >does the PE need this flag?
> it used to be required but recent changes have probably made it
> redundant. in the back of my mind i had the idea that someone other
> than the PE might trigger a STONITH (maybe the DC based on CCM info)
> but perhaps thats not a valid assumption.
Well, the DC does nothing on it's own, all policy decisions are made by
the PE; the only thing the DC does on it's own basically is the election
process and feeding the PE.
> >I'm thinking you are not doing an extra piece of work there, at least
> >not for the better. You are taking the inherent concurrency and
> >parallelism out of the transition graph, by making it impossible to
> >have something depend on two things at once _and_ running those two
Ok, so how do we resolve this in the future? I understand we don't want
to immediately change it - because it works well enough for us to test
the PE, LRM etc with.
How do we want it to work after this first test phase, though?
> >Uhm? There's no ordering loops there.
> A after B
> B after C
> C after A
> Yes I'm a moron for creating such an obvious loop, but loops are still
> a possibility.
The PE will have noticed; the TE does not have to check for it, nor is
the transition graph (neither in your form nor in the one I proposed)
capable of expressing loops, so it can't be in the data ;-)
Lars Marowsky-Brée <lmb at suse.de>
High Availability & Clustering \ ever tried. ever failed. no matter.
SUSE Labs, Research and Development | try again. fail again. fail better.
SUSE LINUX AG - A Novell company \ -- Samuel Beckett
More information about the Linux-HA-Dev