[ClusterLabs Developers] [Linux-ha-dev] moving cluster-glue to github

[Lars Ellenberg]

On Mon, Oct 10, 2016 at 12:07:48PM +0200, Kristoffer Grönlund wrote:
> Adam Spiers <aspiers at suse.com> writes:
> 
> > Kristoffer Gronlund <kgronlund at suse.com> wrote:
> >> We've discussed moving cluster-glue to github.com and the ClusterLabs
> >> organization, but no one has actually done it yet. ;)
> >
> > Out of curiosity what needs to be done for this, other than the
> > obvious "git push" to github, and maybe updating a README / wiki page
> > or two?
> >
> 
> The main thing would be to ensure that everyone who maintains it agrees
> to the move. AFAIK at least Lars Ellenberg and Dejan are both in favor,
> but I am not sure who else might be considered an owner of
> cluster-glue.

Appart from LINBIT, SuSE is the only relevant entity here, I'd say.
We are apparently the only ones that (still) ship cluster-glue.

I'd argue to "let cluster-glue die in peace" [*]

Contributions, if any, will probably only be new stonith/external scripts.
Bring them over to "fence_agents".

Cannot be that difficult to generically bring "stonith/*"
or even only "stonith/external" agents over to the
"fence_agents" compatible API.

Not even necessarily convert to python,
probably one python wrapper would be good enough
for all stonith/external style agents.

[*] the same as you all let "heartbeat"
(the membership and comm layer, not the concept)
die in (mostly) peace.
Yes, still working and maintained and all.  Still alive.
But not really kicking.

----

It's not that there is a steady stream of changes
and contributions for cluster glue.

The only relevant commits in the last six years have been from Linbit
(almost exclusively me), or from SuSE (almost exclusively by Dejan), in
part inspired or on behalf of work or contributions by NTT.

Apart from a few cosmetic patches, the only changes have been to
"hb_report" (which pacemaker feels is obsoleted by crm_report, which
was a fork of hb_report; probably any feature in hb_report that is not
(yet/anymore) in crm_report could and should be merged back, and
hb_report be dropped; maybe that has already happened).

Now, with Dejan no longer being SuSE, that probably leaves lge, lmb, and
krig to "agree" on anything there.

I have no problem using git-remote-hg or mercurial-git to push it over,
or even keep them in sync, having one reflect the other.

Not that it makes any difference, really.
But as I said, I'd prefer to leave it alone if possible.

----

Some historical background for those interested:
the original idea of "stonith plugins" was to have
stonith agents available as a collection of
binary shared objects that could be loaded and mlock'ed
early on, so fencing would work even in "bad situations",
without requiring additional IO or (much) allocations.

Then that was weakened for the "stonith/external" agents,
which would usually be (shell) scripts.

The result was that usually only those scripts would be used.

Now, the "fence agents" are a collection of python scripts,
with few agents still being in C, but the idea of having the
stonith mechanism be "preloaded" has been abandoned completely.

Arguably, if you have not enough resources left to timely execute some
fencing script, you should not be in control of the cluster, and
certainly not try to take over more resources of the to-be-fenced node.

-- 
: Lars Ellenberg
: LINBIT | Keeping the Digital World Running
: DRBD -- Heartbeat -- Corosync -- Pacemaker
: R&D, Integration, Ops, Consulting, Support

DRBD® and LINBIT® are registered trademarks of LINBIT