[Bug 511212] Review Request: cluster-glue - reusable clustering components

[bugzilla at redhat.com]

Please do not reply directly to this email. All additional
comments should be made in the comments box of this bug.


https://bugzilla.redhat.com/show_bug.cgi?id=511212





--- Comment #10 from Andrew Beekhof <andrew at beekhof.net>  2009-07-26 17:13:13 EDT ---
(In reply to comment #9)
> ok. Finally found some time to look at this a bit. ;) 

Much appreciated

> So, my understanding is that this is a newerversion/fork of heartbeat thats
> stripped down and only has the parts pacemaker needs/wants in it. Is that
> correct or am I misunderstanding? :) 

We're in the process of splitting the rest of the codebase.
Its essentially done but just needs the sort of packaging cleanup that we're
doing here before it will be made available for general consumption.  I've also
been on vacation a bit which slowed things down.

The idea is to split the code-base into pieces based on their usage and update
frequency.  So essentially: 
  heartbeat 2.1 + features + bugfixes = cluster-glue + cluster-agents +
heartbeat 3.0 + pacemaker 1.0

or more recently (and relevantly for those not using the crm):
  heartbeat 2.99 + bugfixes = cluster-glue + cluster-agents + heartbeat 3.0

This was mentioned on the mailing list late last month:
   http://www.gossamer-threads.com/lists/linuxha/dev/56290

> 
> First, Fedora really would prefer to avoid Conflicts if at all possible. 
> (See https://fedoraproject.org/wiki/Packaging/Conflicts). 
> So, is there some way we can avoid that here? 

The Conflicts was only intended to be temporary.

I didn't want to force a synchronized update to the heartbeat package just to
get Pacemaker (and therefor cluster-glue) in.

The intention from upstream is that heartbeat 3.0 (which would be the messaging
and membership layer as well as the v1 resource manager) would build against
cluster-glue. 

If/when the cluster-glue package gets approved, I would then submit an update
to the Fedora's heartbeat package and we could then remove the Conflicts
directive.

On the other hand, if Fedora wanted to preserve heartbeat in its current
pre-split state, I figured the Conflicts would (safely) allow that.

> 
> - Can this package just rename the dirs/files that conflict with 'cluster-glue'
> or something and that way they could both be installed and pacemaker could have
> a compile time option to use whichever one. (Or autodetect it based on the
> files found, etc). 

In theory this could be possible, but ideally it wouldn't be necessary since
we'd have both Pacemaker and an updated Heartbeat both using cluster-glue as a
common base.

> 
> - Is using this better than using heartbeat for pacemaker? Or are they the
> same? 

Its a subset, essentially: clplumbing + lrmd + stonith

> If the same, perhaps we hold off on adding this to fedora for now, let
> pacemaker use heartbeat and then down the road when enough folks have moved to
> pacemaker submit this and obsolete heartbeat? 

I don't think that's possible, since heartbeat 2.1 conflicts massively with
Pacemaker.
I suspect there'd be all sorts of compiler problems, not least of all due to
multiple copies of "crm" header files.

> - Perhaps pacemaker could fold in the needed parts of this and just use them
> internally and avoid conflict with heartbeat that way?

That was considered undesirable.

If we were intending to fork the code, then putting it in Pacemaker would make
more sense.
But that would be a last possible resort.


Does that help?

-- 
Configure bugmail: https://bugzilla.redhat.com/userprefs.cgi?tab=email
------- You are receiving this mail because: -------
You are on the CC list for the bug.