[Linux-ha-dev] Re: crm dtd changes

[Andrew]

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 
>> change
>> before committing.
>
> Ok.
>
>>> Mostly right, though I think we could have metadata varying across
>>> 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.

>
>>> Instead of the nvpair we should reference the ocf-resource-agent spec
>>> here.
>> 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 
>> is
>> 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
>>> metadata
>>> to the combined section above.
>>
>> ok.  i'm not filling it in here right now anyway.
>
> Ok.
>
>>> (I have assumed that you 'action_set' is what
>>> you refer to as 'actions' in the definition of the transition_graph
>>> element.)
>>
>> 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
>> constraints.
>>
>> Within a given action set, action N+1 cannot be run before action N
>> completes.
>>
>> Any action from a set can be run independently of any other action 
>> from
>> 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 
> have
> something depend on two things at once _and_ running those two
> concurrently.

true

>
> 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 
a possibility.

>
>>  - 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 
>> "get"
>> 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 
DTD... :)

<insert IRC discussion/>

Ok, I'll take another look and implement the OneTrueAlgorithm for the 
TE once the LRM integration is done.