[prev in list] [next in list] [prev in thread] [next in thread] 

List:       linux-ha-dev
Subject:    Re: [Linux-ha-dev] Topology issues in fencing
From:       Andrew <lists () beekhof ! homeip ! net>
Date:       2004-07-30 7:12:42
Message-ID: D8F84A71-E1F7-11D8-927F-000A95B71D78 () beekhof ! homeip ! net
[Download RAW message or body]


On Jul 29, 2004, at 10:48 AM, Ragnar Kjørstad wrote:

> On Wed, Jul 28, 2004 at 11:09:04AM +0200, Andrew wrote:
>> On Jul 28, 2004, at 5:39 AM, Lars Marowsky-Bree wrote:
>>>> The only thing special with the fencing-daemon is that the CRM is
>>>> also a
>>>> client of it - that's why you need the extentions. I suppose one 
>>>> could
>>>> make the distinction about controlling the daemon and using the 
>>>> daemon
>>>> more explisit by removing the extensions and rather add a seperate 
>>>> API
>>>> for performing fencing with just two actions; "list-fence-targets" 
>>>> and
>>>> "fence".
>>>
>>> That would work.
>>>
>>> Andrew, Alan? ;-) (This is a recurring theme.)
>>
>> I'm a bit thick today... can you explain what you mean by "a separate
>> API" please?
>
> My point was not really related to what the interface is (if it's a
> script with "fence" and "list-fence-targets" actions, or something
> completely different), but merely that it's helpful to describe it as
> two seperate APIs:
> one API is needed for the RM to start, stop and monitor the
> fencing-daemon. This part is exactly the same as the OCF-spec.
> the other part is needed for the RM to initiate fencing. This part is
> not covered by the OCF-spec at all.
>
> I think if you talk about it like this, no one will argue that starting
> / stopping the fencing-daemon should not be done through the OCF-API.
> (Well, I guess we'll find out now)
>
> That's not to say that the two APIs can not be coordinated, and
> implemented in a single script - so the end result is what you 
> described
> in the first place.

Ok.  I was just checking if we were looking to change the way it worked 
or the way we specified the interface :)

>
>>> So okay, if we have a network power switch which can do that, we 
>>> could
>>> extend the concept of several incarnations of any given resource
>>> instance (confused yet by terminology? ;) to even this. But I don't
>>> quite see the perceived benefit for the CRM.
>>
>> It will come for free once incarnations are implemented.  Whether it 
>> is
>> exposed in the GUI is a separate issue.
>
> Well, I guess multiple incarnations of the same instance is a generic
> feature of the RM, not limited to fencing in any way.
>
> This was just part of an example to check that I understood the 
> concepts
> and how you guys had planned this to work.

Np.  Just indicating that it will be a possibility.

_______________________________________________________
Linux-HA-Dev: Linux-HA-Dev@lists.linux-ha.org
http://lists.linux-ha.org/mailman/listinfo/linux-ha-dev
Home Page: http://linux-ha.org/

[prev in list] [next in list] [prev in thread] [next in thread]