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

List:       linux-ha-dev
Subject:    Re: [Linux-ha-dev] Getting an "Official" port number
From:       Alan Robertson <alanr () bell-labs ! com>
Date:       1999-11-26 17:00:45
[Download RAW message or body]

Volker Wiegand wrote:
> 
> On Thu, 25 Nov 1999, Alan Robertson wrote:
> 
> > Volker Wiegand wrote:
> > >
> > > Alan: PLEASE, PLEASE, change your application to include TCP as well as
> > > UDP !!!!!!!!!!!!!!!!!!!!!!!!!!!!!!!!!!!
> > >
> > > We *need* to be able to have stream connections in addition to datagrams.
> >
> > Volker,
> >
> > Since you haven't told me what you're doing, it's no surprise I didn't include
> > it.  I'll see what I can do to get it added.
> >
> Maybe we can revise the application form together.

Feel free to improve on what I sent in, and send it back - probably by private
email.

> I don't do anything
> different from your current way, but would prefer to be more general on
> some of the questions. I do not use TCP nor plan to do it in near future,
> but would like to have the same port number if we decide to use it later.

OK.  It was hard to tell that from tone of your note (all caps and lots of
"!").  It sure sounded like I had run afoul of something specific you had
planned.

> > On the other hand, please stop what you're doing for 20 minutes and write us a
> > summary of your current status.  If you're writing another protocol and haven't
> > told me about it, then I can hardly plan on it, can I?  You can surely afford 20
> > minutes every week or two.
> >
> Yes, Sir, you are absolutely right. I was not playing by the rules. Please
> take my apologies.

Rules?  What Rules?	 :-)

> My current work concentrates on design and initial coding for the
> following modules:
> 
> (1) Framework for process startup and IPC, based upon pluggable interfaces
>     for heartbeat, service+system monitoring, configuration
>     reading+updating, cluster topology+strategy, alerting and application
>     interfacing
> 
> (2) Definition of a flexible, hierarchical config file format
> 
> (3) Layout and standardized interface for a central shared memory
> 
> (4) Heartbeat modules based upon Alan's current implementation
> 
> (5) System monitoring, learning from UCD-SNMP
> 
> (6) Application monitoring, learning from Mon and PIKT
> 
> (7) Configuration reading module, filling the ShMem
> 
> (8) Configuration version control, based upon CVS
> 
> (9) Alerting module (mail, pager, syslog, traps)
> 
> (10) SNMP Interface, based upon the AgentX protocol
>      (only for diagnosing the cluster, no manipulation)
> 
> (11) BMC Patrol knowledge module for cluster diagnostics

BMC Patrol is a commercial product.  My sense is that being compatible with a
commercial product which isn't cluster oriented is a low priority.  What did you
have in mind here?
 
> (12) Cluster communication on resources and services
> 
> (13) (Initial, primitive) Cluster strategy module to synchronize the
>      most effective resource distribution, and execute it
> 
> (14) Application interfaces:
>      - Wrappers for start/stop/status of non-aware applications
>      - Requirements collection for "Cluster aware API"
> 
> Status: requirements and design roughly done, coding started on all
> modules, so that the interfaces are done first, and after inclusion into
> Alan's CVS they can be filled with life from different persons.
> 
> > When we last talked about it, you had expressed a desire to go forward
> > together.  I'd love to do that.  However, it is impossible to go forward *with*
> > you if you don't communicate.
> >
> I was able to do a lot of requirement and design docs in the previous two
> weeks, and have started coding beginning of this week. This week was a bit
> harder due to many requests in the office and from my family. I know this
> is no excuse, so please again let me apologize for not communicating
> sufficiently.

Apologies accepted.  It is hard for me to know how to plan around what you're
doing when I don't know what it is, and especially when it's so amazingly broad
in scope as you indicated below.

> My plan was (and if you can accept it still is) to setup a common
> "infrastructure" that can easily be worked upon by several people
> *simultaneously*.

Yes, I suspect we can manage a moderate number of simultaneous developers (maybe
up to a dozen or so).  I know where 3 or 4 part time people might come from.  Do
you have any other candidates in mind?  I just got some inquiries from SGI
hinting that they might be interested in helping out...
 
> > I am about to run out of things to do in the base heartbeat code.  Within a few
> > days, I will go forward into other things.  I will chooose what I do
> > next on the basis of what I believe needs doing most.  Without any information
> > beyond an initial email from you, I'll probably head straight into implementing
> > areas that you might already be doing.
> >
> As you know, I have been heavily thinking about using existing protocols,
> like SNMP or ACE/TAO/CORBA for the underlying message exchange. Looking
> closer at Ensemble I found also beauty in it. But as you asked (and also
> convinced) me, I have not changed the way things are currently run, at
> least not for the protocol or your message exchange mechanisms. I merely
> build upon your work.

Changing things is OK.  It's good to know why and what the results are expected
to be.

A general comment:
My sense of this is that you've bitten off a huge amount to start with.  You
have outlined at least 5-10 staff years of work.  I am a little concerned that
too much has to be done before we get much in the way of results...

What is your implementation strategy here?  My bias is to choose a strategy
which gives us results quickly, and allows us to evolve.  I think this is very
consistent with the strengths and weaknesses of the open source development
model.

On the other hand, it is good to lay out the interfaces very early on, so I
applaud this.

If you're going to have so many different pluggable modules, and interfaces, I
am concerned about managing a relatively monolithic development of such size in
the open source model.

Regarding CORBA:
The talk I heard on our local experience with CORBA was quite positive.  It
might be worth considering.

	-- Alan Robertson
	   alanr@bell-labs.com

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

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