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

[Dejan Muhamedagic]

Hi Lars,

On Mon, Oct 10, 2016 at 05:42:12PM +0200, Lars Ellenberg wrote:
> 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.

Debian? Ubuntu? Probably some others too, there's a zillion of
Linux distros :)

> 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.

Probably not. Either API is no rocket science :)

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

That's also an option. Though I do find a stonith use a bit
easier (on the eyes).

> [*] 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.

That would certainly be a shame, but I'm not sure if it is really
so. Apart from occasional cries that it is
legacy-and-dont-you-dare-use-it-as-it-is-history

The glue, apart from stonith agents, is still used, at least by
booth. Though Jan (Poki) recently added support for libqb there
too. Anyway, I find quite a few parts of glue just fine.  If the
software is doing whatever it's supposed to do and there's
somebody knowing how to fix it if need be, why throw it away or,
as you say, let it die (what does that actually mean).  I'm not
in for long discussions, just wonder if moving bits around for no
obvious reason is the best way to serve users.  After all,
nothing is forever and a bit of competition could be healthy ;-)

> ----
> 
> 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.

What about NTT? Also, even if I'm not with suse, I'm still
around. Though sometimes I do wonder what for ;-}

> 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.

More resources (as in memory/cpu) nowadays.

> 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.

Indeed. Which reminds me of the case when corosync (or heartbeat)
is happily ticking while the rest of the computer comes to a
crawl.

Cheers,

Dejan

> -- 
> : 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
> 
> _______________________________________________
> Developers mailing list
> Developers at clusterlabs.org
> http://clusterlabs.org/mailman/listinfo/developers