Re: [Linux-ha-dev] Re: Failsafe Licence LGPL / GPL confusion

On Sat, 2003-11-29 at 09:57, Lars Marowsky-Bree wrote:
> On 2003-11-28T15:43:00,
>    Kashif Shaikh <[email protected]> said:
> 
> Hi Kashif, I'd suggest to move the heartbeat development related thread
> to the linux-ha-dev list. As that's the bulk of this mail except for the
> SGI license question, I'm cc'ing linux-ha-dev directly.
> 
> > > SGI owns most of the files and would have to reevaluate the copyright
> > > decisions.
> > Maybe someone from SGI can comment here? Otherwise someone(me?) could just
> > strip out GPL symbols from the LGPL header files.
> 
> I'm not sure whether that would be helpful for anyone, actually.
> 
> What is your intention?

My intention was to make the cms/gcs layer independent of all other
subsystems, since the cms/gcs API is LGPL. But these APIs are mixed with
CDB, which has a GPL API. So any 'third-party' process-group
applications could cleanly interact with cms/gcs API, without having to
touch any CDB GPL symbols/data-structures. So it's only helpful to
people who don't really need the CDB like me.


> I would disagree with that. The CMS layer is nice, but the algorithm
> used is pure horror - its N! complexity, and will easily saturate a
> 100mbit/s network and use substantial bandwidth on gigE, and that's
> ignoring the latency issues it has. The problem is that it is mapping an
> algorithm designed for a ring topology to a broadcast based network,
> which does imply a certain overhead.

CMS could be modified to use hardware ethernet mcasts. 

> The other parts do have their good sides. The CDB is a very, very nice
> concept (albeit the implementation sucks). 
...
> > the cdb should be placed over the cms/gcs layer, but it's pointless
> > since cdb uses rpc for communication and will be difficult to use
> > gcs.
> 
> Yes. The CDB is a sucky implementation. The original papers called for
> the cdb to run on top of cms/gcs, but I guess then they found out that
> they needed info from the CDB to bootstrap the startup of cms/gcs, and
> thus the layers blurred and complexity exploded.

The CDB API is simple, but you need a custom GUI front-end to read/write
key/vals or try to descend the tree using cryptic cdbutils cli(which is
one of the reasons I think why SGI wrote dozens of CLI programs to
manipulate the CDB). 

Perhaps for the future CDB/CIB, there could be a graphical 'CIB Editor'
similar to the 'Windows Registry' or Gnome's gconf. And the CDB/CIB
manipulation could possibly be SQL-based so that any front-end can
interact with the db using normal SQL commands. Though you would need a
replicated SQL cluster with Postgres + replication component.


> Now, the CIB _is_ adding complexity. I am not disagreeing. Let me try to
> convince you that it is necessary complexity. If you look at the
> postings to the mailing lists, a substantial number of bugs are due to
> configuration mismatches between the two nodes, and users being unsure
> about how to change the configuration online. This alone needs
> addressing, but I'm very afraid of how often users would get it wrong
> with even 3 or 4 nodes. And there are reasonably sane setups where 3 or
> 4 nodes make quite a bit of sense.

Yes I agree CIB is needed -- but what I found out, once configuration is
done(especially for HA), the information is set in stone after cluster
is used in production. Meaning 99% of the time you are going to be doing
reads form the CIB and 1% of time writing(i.e adding new resource,
changing IP address, etc). 

So maybe all that is needed is a simple file-syncer using Dnotify/FAM or
special commands like this:
#!/bin/sh

# lock files
/usr/sbin/lockCIB write /etc/node.conf
/usr/sbin/lockCIB write /etc/resources.conf

# change the files.
ed - /etc/node.conf <<!
g/CLUSTER_IP/d
w
!

ed - /etc/resources.conf <<!
g/PARAM/d
w
!

/usr/sbin/unlockCIB /etc/node.conf
/usr/sbin/unlockCIB /etc/resources.conf

This is just an idea, but it's not perfect(it has race conditions -- a
global lock would be needed, but you get the idea). This allows us to
write rich shell scripts and any program(perl, C, C++) can access the DB
cleanly without going through a special API.

Kashif