High-Availability Linux Development List <[email protected]> 
wrote: 
> On Fri, Apr 11, 2008 at 3:42 PM, Lars Marowsky-Bree <[EMAIL PROTECTED]> wrote:
> > On 2008-04-11T13:55:04, Andrew Beekhof <[EMAIL PROTECTED]> wrote:
> >
> >  > As Lars mentioned yesterday, the reason for 2.1.4 is to allow time 
for some
> >  > additional project changes (both managerial and technical).
> >  >
> >  > Part of these changes are to split the, currently monolithic, 
Heartbeat
> >  > project into logical components that can be updated/released/replaced
> >  > independently of the other pieces.
> >  >
> >  > The current plan is to have 4 pieces (Two of which already exist.  
All
> >  > names are suggestions only).
> >  > In order of build sequence, they are:
> >  > * heartbeat-core
> >  > * heartbeat-stack
> >  > * pacemaker
> >  > * cluster-extras
> >
> >  For consistency, I'd suggest to name them
> >  linux-ha-{core,heartbeat,pacemaker,mgmt}, instead of jumping all over
> >  the place with the names ;-)
> >
> >  (We could shorten linux-ha- to lha-, but why hurt the brand?)
> 
> 
> Lots of '-'s in there, but I don't mind too much
> Except for pacemaker, which wont be adopting either form of the prefix.
> 
> 
> 
> > > * heartbeat-core (alternate name: cluster-core, lha-core)
> >  > This project would contain all the pieces relevant to the operation 
of a
> >  > single node.
> >  > Conceptually, the project would include:
> >  >  - clplumbing (including logging)
> >  >  - pils
> >
> >  We might even merge these two into "plumbing".
> 
> I see you're already into naming the packages :-)
> 
> >  >  - lrm
> >  >  - resource agents
> >  >  - stonith plugins + cli
> >
> >  I agree.
> >
> >  linux-ha-core-{plumbing,lrm,ra,stonith}
> 
> fair enough
> 
> >
> >  > * heartbeat-stack
> >
> >  I prefer linux-ha-heartbeat.
> 
> >  linux-ha-heartbeat; there's some opportunity to split this into v1 and
> >  v2, but I'm not sure this bit is worth the effort.
> 
> agreed
> 
> >  > The next two projects are already operational and are presented 
mostly for
> >  > the sake of completeness.
> >  >
> >  >
> >  > * pacemaker
> >  > This project contains all the pieces relevant to the v2/CRM/Pacemaker
> >  > cluster resource manager.
> >  > Conceptually, the project includes:
> >  >  - cts
> >  >  - crm command line tools
> >  >  - crm (cib, crmd, pengine, tengine, pingd, attrd, OpenAIS plugin)
> >
> >  Does hb_report go here as well and gets renamed to
> >  cluster_support_report maybe?
> 
> makes sense - most of the functionality (i think) is related to
> pacemaker and getting it's PE files, configs, etc
> 
> dejan?
> 
> >  linux-ha-pacemaker{,-cts}? Not sure about splitting off CTS, actually,
> >  but worth a thought. Don't see anything else here which could sanely be
> >  split-off.
> 
> Just "pacemaker".  You're getting a bit carried away with the prefix 
there :-)
> And I agree that there is limited value in splitting off CTS -
> especially if we're going to advocate its use more and more.
> 
> >  in the packag
> >
> >
> >  > * cluster-extras (currently known as pygui which isn't the best name)
> >  > This project contains high-level management tools and infrastructure.
> >  > Conceptually, the project includes:
> >  >  - mgmtd
> >  >  - cim
> >  >  - snmp
> >  >  - tsa_plugin
> >  >  - gui (client)
> >
> >  linux-ha-mgmt-{daemon,cim,snmp,tsa,gui1}
> 
> s/linux-ha/cluster/ ?
> 
> 
> >  (I suggest "gui1" or something similar as I expect we'd have several 
new
> >  GUIs in the future.)
> 
> gui1 looks horrid
> how about pygui (since its written in python) ?

I just want to add my two cents here, with my little experience as port 
maintainer for OpenBSD. 
First, I do not care about the names of the packages, anyone would be 
fine ;)
Second, please do not split everything into a single separate software. Not 
every OS/Distribution is like Debian, with its thousands small packages. 
E.g. my first porting attemt was to create the same amount of sub-packages 
as I install on e.g. suse. That was rejected, "we are not debian". Therefore 
the OpenBSD port is divided into a main package, and a -gui, and a -snmp 
package, just only because of the different dependencies of the different 
parts.
However, I think I can deal with any solution, its just that one will be 
easier than an other...

cheers
Sebastian

_______________________________________________________
Linux-HA-Dev: [email protected]
http://lists.linux-ha.org/mailman/listinfo/linux-ha-dev
Home Page: http://linux-ha.org/

Reply via email to