[Linux-ha-dev] Adding "reload" to the OCF specification

Alan Robertson alanr at unix.sh
Tue Aug 15 17:10:10 MDT 2006


Andrew Beekhof wrote:
> On 8/15/06, Alan Robertson <alanr at unix.sh> wrote:
>> Andrew Beekhof wrote:
>> > On 6/28/06, Lars Marowsky-Bree <lmb at suse.de> wrote:
>> >> On 2006-06-15T18:26:24, Lars Marowsky-Bree <lmb at suse.de> wrote:
>> >>
>> >> Lack of disagreement implies agreement.
>> >>
>> >> Alan, how about we plan this as an enhancement for 2.0.7?
>> >
>> > Unlikely.
>> > This is a significant departure from the current design and a major
>> > piece of work.
>> > Essentially all the same problems from the "migrate" discussion apply.
>>
>>
>> I don't quite follow that.
>>
>> The assumption here is that if you enable reload, that it has no visible
>> negative effect on its dependent children.
>>
>> So, you sneak in and do it, and nothing else is effected.
>>
> 
> right - lmb helped me understand that further on in the thread.
> the problem is knowing what variables cause a reload and which ones
> cause a restart.
> to know that we need to change the lrm

Sorry I replied before reading the rest of the thread.  Mea culpa.

That information is present in the OCF specified metadata.  The LRM
certainly doesn't have any knowledge of XML that would tell it, nor can
it be determined without that information.

I know you've resisted this so far -- but it's in that nasty metadata  ;-)

The metadata was clearly intended for something CRM-like to use.

It's a design decision that we've made that has so far kept the CRM from
reading it.

So, perhaps the CIB (through the GUI or user editing) should give you
some more hints.  But, IMHO, it's not an LRM issue.  The correct
information to determine this should be present in the CIB -- and not
determined at run time.

Or maybe I'm still confused (certainly possible).

-- 
    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


More information about the Linux-HA-Dev mailing list