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

List:       linux-ha-dev
Subject:    Re: [Linux-ha-dev] Cluster management thoughts
From:       Alan Robertson <alanr () unix ! sh>
Date:       2004-12-28 15:30:00
Message-ID: 41D17BF8.5040101 () unix ! sh
[Download RAW message or body]

Andrew Beekhof wrote:
> After a productive IRC chat with sunjd, I'd like to clarify my position 
> on the management tool...
> 
> First up, I am not against having a daemon.  On the contrary, I think 
> they are likely to be a necessity.  What I /am/ advocating however is 
> that we first start with a higher level unification API/library that 
> spans the CCM, CIB, HA, and whatever else is required.
> 
> By way of example, where the CIB API allows us to find out the status of 
> all nodes in the cluster, the higher level API would process the CIB's 
> result to tell you the active resources on a specific node.  Or where 
> the CIB API allows you to update the CIB, the higher level would create 
> a resource and add it to CIB.
> 
> My rationale here is that if we start with an API, then the number and 
> types of admin clients are endless while still limiting the duplication 
> of common functionality.  The same API that we use to build a SNMP 
> notification daemon could also be used to build a daemon that web 
> clients can connect to, or a local GUI application, or a GUI application 
> that talks to a daemon, or, or... do people see where I'm going with this?
> 
> By going straight to the daemon I feel we are make life harder for 
> ourselves... the type of daemon you need/want for a web based client 
> isnt the same as for a desktop GUI application nor the same for a SNMP 
> client.

This is exactly what this daemon does...  It is only for consolidating the 
functions into one place.  It just doesn't expose a library interface.  If 
such a library were built, it would probably be a good thing, but the API 
that the daemon exposes is much more interesting than the internals of how 
it's implemented (i.e., whether it uses a consolidated library, etc.)

> The second thought is to think about migrating some of the configuration 
> from ha.cf into the CIB.
> 
> Obviously there is the possibility for a chicken and egg situation here 
> so not everything is appropriate to be moved, but everything that does 
> is one less thing to get wrong.

Yeah.  This is totally a chicken-and-egg issue.  The CIB can't be started 
first, because it needs heartbeat communication.  Heartbeat communication 
can't start because it needs CIB configuration information.  I'm not 
remotely interested in solving this in release 2.0.x.  Maybe for 2.2.  But, 
definitely not for 2.0.x.

> Changing an option (such as the log level or whether sub-system X 
> enables apphbd support) is then simply a matter of updating the CIB 
> which pushes the change to all nodes.

No argument.  Let's get some experience in making this work, and some room 
to breathe from having it actually work first.


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