[Linux-ha-dev] LRM Testing

[Andrew]

> Andrew wrote:
>>
>> On Jun 3, 2004, at 8:44 PM, Lars Marowsky-Bree wrote:
>>
>>> On 2004-06-03T20:06:22,
>>>    Andrew <> said:
>>>
>>>> only if i'm allowed to query the LRM for that info and cache the info
in the CIB.  which i was under the impression was a no-no.  certainly
the API right now does not allow for it.... "lrmadmin -L" currently
returns nothing for a freshly started lrmd.
>>>
>>>
>>> As Alan also confirmed, the LRM must be able to tell us the list of
Resource Agents installed locally. This is a must.
>>
>>
>> 10-4... i shall make adjustments to assume this behaviour from the LRM.
>>  hmm come to think of it, i'm not sure i unadjusted them the first
>> time...
>>
>>>
>>>> if we do ask the LRM for a list of all the RAs it supports, i would
argue that in that information it could and perhaps should also
return the metadata.  otherwise we then have to make separate queries
for each
>>>> and every RA which to me seems inefficient since there may be many of
them.
>>>
>>>
>>> ... whether or not we loop around the metadata or have it provided to us
>>> in one go by the LRM I don't care about. I agree it would be more
efficient if the LRM did that, as _it_ is allowed to cache that
information on startup and only update it when it detects a RA newly
installed or removed.
>>
>>
>> Personally i think the LRM should be responsible for it.  otherwise the
CRM will still end up knowing about the internals of resources which I
would like to avoid.  There is also the issue of defaults for the other
RA classes, though I can also imagine versions being hacked into the
other types and i'd rather keep the CRM out of dealing with that if I
can :)
>
> I'm not sure which things you're referring to, so I'll state a few
things here, and you can tell me what you really meant...
>
> a) The LRM Must provide a list of resource classes on demand
>
> b) The LRM Must provide a list of resource agents for any given class
> 	on demand.
>
> c) The LRM Must provide some kind of metadata for every resource, whether
> 	OCF-compliant or not.  OCF resource agents will have *much*
> 	more metadata, however.  You should lobby for specific data
> 	to be provided by the non-OCF resource agents metadata
> 	(which they will have to make up on the fly).
>
> I think these are the important issues connected with the kinds of
things you might have been talking about in your "should be responsible"
statement
> above.  But, maybe I misunderstood...

no, no, appologies for not being clear.

in my ideal world, i would include all 3 in the list of LRM duties. a) and
b) are no brainers since they're already in the API.

I see that there are three parts to c).  First I believe that the LRM
should be providing this information for classes that support it
(currently only OCF).

The second is that it would be nice, but not essential, if the LRM
provided something for non-OCF RAs so we can treat all resources the same.

The last is that the metadata the CRM would be after during the inital
"what do you support" discovery phase only constitutes the version number
at this stage.  And as per lmb's email, we have good reason to avoid
expanding this list.

>
> --
>      Alan Robertson <alanr at unix.sh>
>
> "Openness is the foundation and preservative of friendship...  Let me claim
> from you at all times your undisguised opinions." - William Wilberforce
>
> _______________________________________________________
> Linux-HA-Dev: Linux-HA-Dev at lists.linux-ha.org
> http://lists.linux-ha.org/mailman/listinfo/linux-ha-dev
> Home Page: http://linux-ha.org/
>