[Linux-ha-dev] Re: crm dtd changes
lists at beekhof.homeip.net
Tue Jul 6 08:15:02 MDT 2004
On Jul 6, 2004, at 2:52 PM, Lars Marowsky-Bree wrote:
> On 2004-07-06T12:43:40,
> Andrew <lists at beekhof.homeip.net> said:
>>> Why do you kick out the timing parameters for a resource instance? I
>>> don't approve of that; where else are they stored?
>> yes the timings should go back in. i had something else in mind but
>> then realized what this was about. evidently i didn't revert the
>> before committing.
>>> Mostly right, though I think we could have metadata varying across
>>> RA versions now, and have several (class, type, version) entries in
>>> 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.
>>> Instead of the nvpair we should reference the ocf-resource-agent spec
>> see latest commit :)
> Reference, not include ;-)
>>> The "usually" still applies as we only shoot if told to do so or if a
>>> resource dependency requires it... ;-)
>> This might be an implementation detail.
>> Perhaps the name should be changed, but the intent is that when this
>> set, a STONITH action is absolutely required. So if we detect an
>> unclean exit, but *dont* want to perform fencing, then we wouldn't set
>> this attribute. Make sense?
> 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.
>>> It essentially ends up being EMPTY because we have migrated the
>>> to the combined section above.
>> ok. i'm not filling it in here right now anyway.
>>> (I have assumed that you 'action_set' is what
>>> you refer to as 'actions' in the definition of the transition_graph
>> an action set (which i thought i described somewhere :puzzlement: ) is
>> a list of dependent actions as defined by the presence of rsc_to_rsc
>> Within a given action set, action N+1 cannot be run before action N
>> Any action from a set can be run independently of any other action
>> any *other* set.
> Uhm. Ok. I'm not sure I like that approach.
>>> I don't like the new transition_graph structure at all. What were you
>>> trying to achieve?
>> Here goes...
>> The premise is that the PE has already mostly solved the problem and
>> has all the data structures unpacked (in particular the rsc_to_rsc
>> constraints and the actions).
> Yes, obviously.
>> Doing an extra piece of work there:
> 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
> something depend on two things at once _and_ running those two
> The transition graph _is_ a graph, not an ordered list.
>> - Simplified the TE *a lot*
> I'll give you that, but also much less powerful; your design strikes me
> as too limitted.
fair enough - its been a handy test tool though :)
> The idea was to have a data structure which can essentially represent
> actions triggered by certain events - most of the time the events would
> actually be created by the results of previously run actions.
>> - By using the constraints directly the PE can detect (and maybe have
>> a stab at a solution for) ordering loops
> 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
>> - Faster? Less packing and unpacking, less time recreating the
>> calculation state that already existed in the PE.
> I don't follow you here, I don't think this is much of an issue.
hence the "?". I was just trying to build my case :)
>> There was also an element of circumstance to it. I didn't really
>> what you had in mind with the whole synapse thing nor see the
>> advantages (probably a connection there) but I needed a TE and you had
>> pressing matters to attend to. So I took a "keep it simple" approach
>> which seemed (to me) to do pretty much the same thing.
> Ah ;-) Now we are getting to it.
> What did you not follow in my TE proposal? If you ask me a question,
> maybe I can answer ;-)
I dont remember anymore, all of your proposal has been wiped from the
<insert IRC discussion/>
Ok, I'll take another look and implement the OneTrueAlgorithm for the
TE once the LRM integration is done.
More information about the Linux-HA-Dev