[Linux-ha-dev] A proposal for setup and management tools

Andrew Beekhof beekhof at gmail.com
Mon Dec 20 00:53:38 MST 2004


On Mon, 20 Dec 2004 08:33:02 +0100, Andrew Beekhof <beekhof at gmail.com> wrote:
> On Mon, 20 Dec 2004 13:58:30 +0800, Sun Jiang Dong <hasjd at cn.ibm.com> wrote:
> >
> >
> > Andrew Beekhof wrote:
> > > On Fri, 17 Dec 2004 17:20:11 +0800, Sun Jiang Dong <hasjd at cn.ibm.com> wrote:
> > >
> > >>
> > >>Andrew Beekhof wrote:
> > >>
> > >>>On Fri, 17 Dec 2004 11:08:00 +0800, Sun Jiang Dong <hasjd at cn.ibm.com> wrote:
> > >>>
> > >>>
> > >>>>Andrew Beekhof wrote:
> > >>>>
> > >>>>
> > >>>>>>1) Need to add client library for some daemons, such as crmd.
> > >>>>>>   It's not suitable to call a *admin*tools to interact with a daemon in another
> > >>>>>>program written or a python binding library.
> > >>>>>
> > >>>>>
> > >>>>>Can you clarify what you're saying here?  I'm not convinced I
> > >>>>>understand you accurately enough to comment.
> > >>>>>
> > >>>>
> > >>>>Formerly I think there should be a client lib of crmd for accessing some
> > >>>>resource functions instead of using crmadmin.
> > >>>>
> > >>>>If I comprehend the following correctly, now to use the new CIB client API,
> > >>>>we can manage the resource completely and get all information. So now the former
> > >>>>issue  doesn't exist any more. Right?
> > >>>
> > >>>
> > >>>Well it depends how you look at it.
> > >>>
> > >>>Certainly the CIB now has an API (in the more traditional sense of an
> > >>>API) that people can use to configure the CRM, so thats a non issue.
> > >>>
> > >>>The CRM also has what I would consider an API (others may differ in
> > >>>that view), however it is based on messages (as defined in
> > >>>crm-1.0.dtd) rather than function calls.  crmadin is therefor only one
> > >>>possible implementation of an admin tool for that API.
> > >>>
> > >>>Does this make sense?
> > >>>
> > >>>Perhaps there is value in creating a function based API for the CRM,
> > >>>but as yet I'm not terribly convinced of that - particularly now that
> > >>>the CIB has one which does pretty much everything anyway.  I am open
> > >>>to persuasion however.
> > >>>
> > >>
> > >>Now that we can do pretty much everything on resources via CIB (client API),
> > >>then all is ok.  Anyway, we want to provide a tool covering the resource
> > >>management, not to manage CRM itself. ;-)
> > >>
> > >
> > >
> > > Ok, I'm lost now.  The architectures had the ccm, apphbd, crmd,
> > > stonithd, heartbeat, ... thats a whole lot more than resource
> > > management.
> > >
> > > So if "just" resource management in 2.0 is the goal, then 90% of what
> > > you are proposing already exists and, well, I'm confused.
> > >
> > > Can you go back to the beginning and clarify what you're trying to
> > > solve here.  Because the first line from your first email was "We'll
> > > begin to implement setup and management tools for linux-ha cluster"
> > > which to me meant more than resource management.
> > >
> > Sure. Our goal is to cover as many subsystems of linux-ha as possible , not only
> > the resource management.
> >
> 
> Ok.  But that doesnt match what you had written above:
> 
> > >>...  Anyway, we want to provide a tool covering the resource
> > >>management, not to manage CRM itself. ;-)
> 
> Remember what C, R and M actually stand for :)
> 
> Anyway, I'd like to ask a couple of question at this point...
> - Is this managment tool intended to be independant of the resource
> manager? Or CRM specific?
> - What other design guidelines are there?
> 
> Once I know those answers, maybe my input will be of more use.
> 

Can I also suggest that before we decide /how/ it will work, we
specify /what/ its going to do.

So decide... what information, from what sub-systems, how will it be
organized, and what can and cannot be modified.


More information about the Linux-HA-Dev mailing list