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

List:       linux-ha-dev
Subject:    Re: [Linux-ha-dev] lha-md model.
From:       Alan Robertson <alanr () unix ! sh>
Date:       2005-02-23 5:35:24
Message-ID: 421C161C.6060708 () unix ! sh
[Download RAW message or body]

Kashif Shaikh wrote:
> 
>>-----Original Message-----
>>From: linux-ha-dev-bounces@lists.linux-ha.org
>>[mailto:linux-ha-dev-bounces@lists.linux-ha.org]On Behalf Of
>>Andrew Beekhof (GMail)
>>Sent: Thursday, February 17, 2005 2:13 PM
>>To: High-Availability Linux Development List
>>Subject: Re: [Linux-ha-dev] lha-md model.
>>
>>
>>
>>On Feb 17, 2005, at 7:39 PM, Kashif Shaikh wrote:
>>
>>>So unless management operations are delegated to a cluster-wide
>>>daemon(i.e
>>>CRM), I think it will be better to design lha-md as a multi-node
>>>resource(if
>>>that is possible).
>>>
>>
>>I'm still yet to see the need for this.
> 
> 
> All I'm saying is that the 'management logic' has to be handled by some
> layer cluster-wide. It has to fit in somewhere.

Not true, AFAIK.  You haven't given any examples of it (including below). 
You're asserting that it's true doesn't make it true.

 > It will require
> communication and coordination between the many layers CRM/CCM/CIB.  The
> management logic should be extendable so that other vendors/people can
> add/remove functionality(i.e. custom GUIs).
> 
> Here's a simple situation:
> 
> - member1 is carrying out Meatware stonith request for dead member3, which
> requires authorization from Administrator.
> - meanwhile, lha-md is running on member2, the current DC. How will lha-md
> be able to present this stonith request to a front-end, since it can't find
> out about this request(unless CRM tells lha-md about it)?

There are many solutions to this problem that don't require your 
distributed management paradigm.  For example, consolidating logs onto a 
single machine and monitoring it.  This is easy, recommended, and makes 
your artificially created problem go away.  I could name 3 or 4 simple 
other solutions to the same problem.  Your choice about which one to use. 
But most of them are simpler than what you're proposing.

> There are many uses for a management daemon that can perform distributed
> operations cluster-wide, especially operations that can't/don't fit into any
> particular underlying layer(CRM/CCM/CIB).

If you say so.  You haven't given any examples *from our problem domain* 
yet though...  [There are many such problems out there, but we haven't yet 
seen any evidence of them being in our problem domain].  If you come up 
with one, be sure and let us know ;-).

Our problem domain:
	Supercharged-init-on-steroids.  (to make it short-and-sweet)

I don't see the value in going out of our way to try and implement a 
solution to a moderately hard problem, when we demonstrably have no need 
for this solution.  This is definitely one of those "solutions looking for 
a problem" as far as our needs are concerned.

What we have works very well indeed, and it is more than an order of 
magnitude simpler than trying to manage things using distributed logic.

Since release 1 manages its 2-node clusters by distributed logic, I can 
assure you that release 2 is a big improvement in this regard.  I'd never 
take that road again.  Been there.  Done that.  Have the scars to prove it.


	Complexity is the Enemy of Reliability.


-- 
     Alan Robertson <alanr@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@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]