[Debian-ha-maintainers] Linux-HA Jessie release goals

[Andrew Beekhof]

On 19/05/2013, at 7:32 PM, Martin Gerhard Loschwitz <martin.loschwitz at hastexo.com> wrote:

> Folks,
> 
> with Wheezy being done, it's a good point in time now to discuss the release goals for the
> Linux-HA stack in Jessie. Right now, we have Pacemaker 1.1.9 along with its dependen-
> cies in Experimental (including Corosync 2), uploading this to Unstable is the next logical
> step. According to Pacemaker's upstream Andrew Beekhof, Pacemaker 1.1.9 continues to
> work with Corosync 1.x, so backporting Pacemaker afterwards should not be too big of an
> issue either.
> 
> 1.However, please keep in mind that the cluster stack has been a moving target lately with
> things changing on a regular base. According to, again, Andrew Beekhof, distributions
> should take the approach that Red Hat will take for its RHEL 7 distribution,

Not because thats what RHEL is doing though.  
I suggest it because option 3 is the better/cleaner/$attribute solution.

> documented as
> option 3 here:
> 
> http://theclusterguy.clusterlabs.org/post/34604901720/pacemaker-and-cluster-filesystems
> 
> I am very much all in for that because it allows us to get rid of redhat-cluster (including all
> the things like cman and rgmanager) and means a lot of work less. The negative side is
> we would effectively be losing support for OCFS2+Pacemaker (and probably we would be
> losing support for cLVMd+Pacemaker, too, unless someone patches it to support Corosync
> 2.0, of course). 

This would be a good point to sync with SUSE on, since they will presumably continue to ship/support OCFS2 after switching to corosync2.

> 
> 2. Another issue is Heartbeat support. Andres Rodriguez has brought up the idea of drop-
> ping support for the Heartbeat communication stack altogether to force a migration to the
> new Corosync 2. While I was originally reluctant to this, by now I think there are quite some
> reasons speaking for it.
> 
> There has not been a single Heartbeat release for almost two years now,

Realistically its been even longer.
Apart from the crm bits, very little was changing in releases since even 2.0.0

I'd love to see someone get really stuck into the codebase, to clean it up and push it forward.
But I don't see that happening any time soon.

> according to
> Philipp Marek from LINBIT, Heartbeat's current upstream, a new version 3.0.6 is planned:
> 
> 2013-05-19 #linux-ha at Freenode
> (09:33:54) <flip214> Madkiss: there'll be a heartbeat 3.0.6 in the near future…
> 
> However, there were no commits to Heartbeat's Mercurial repository either, so I have no
> idea what it will deliver. Thing is: If we plan to keep Heartbeat support in Pacemaker even
> for Jessie, that would refer to a timeframe of 5-6 years from now on, because if Ubuntu 
> 14.04 LTS has HB support (and we plan to keep the packages in Sync as far as possible), 
> we need to support it until 2019. Which, if I am honest, scares  me a bit. Plus, we have no 
> idea if upstream, at some point, will simply decide to drop the Heartbeat support altogether 
> (Andrew, your input would be highly appreciated on this one).

As long as the support overhead is minimal, which it has been so far and I see no reason it will change, I have no problem leaving it in.
Once upon a time there were some features we were considering that would only work with corosync, but I they've been put on the back-burner, dropped or modified.

> 
> 3. We will, however, need to provide some sort of upgrade path for this. People running a
> cluster with Pacemaker as plugin at the moment will blow up their setup by updating to
> Pacemaker 1.1.9+Corosync 2 because that does not support the plugin stuff anymore, and
> Pacemaker will lose the plugin RSN anyway, according to Andrew.

Only on RHEL. The upstream repo will not be affected.
The plugin falls into the same category as Heartbeat.

> The same goes for the
> DLM mess; people running Pacemaker+CMAN (or even those on Squeeze running Pace-
> maker with the old control daemons) will blow their setups up irreparably, in fact, switching
> to option 3 in the aforementioned document means effectively removing support for cLVMd
> from Debian (OCFS2 can still work as it has its own clustering mode).
> 
> 4. Last but not least, there's the cluster control shell thing. We need to decide is which shell 
> we will be supporting. crmsh is packaged for Debian and in the archive already; my first 
> attempt to package PCS was rejected by Luca Falavigna last week, I am preparing an 
> updated build. However, packaging PCS is a bit hairy for numerous reasons, one being the 
> fact that pcsd, the tool's internal daemon, requires ruby gems which are non packaged at the 
> moment. I took the liberty to create some preliminary packages of these ruby gems and will 
> be asking the Debian ruby people to give me a helping hand on this one.
> 
> It looks like PCS will soon be merged into Pacemaker anyway,

Absolutely not.  I did suggest this once on IRC, but it was only to get a reaction from SUSE.

> or at least that is what I hear.
> Andrew, could you comment on this one? Thanks in advance!

Of course with my RH hat on I'm going to push pcs, but honestly, go with whichever one suits you and/or your userbase.
Both have pros and cons, its not my call.

> 
> Given that still 98% of all examples out in the intarwebs use the "crm" command, which is the
> crmsh, and given that crmsh has proven to be useful and usable lately, I would prefer to keep
> both packages (or keep crmsh if PCS becomes part of Pacemaker anyway)
> 
> Summary: I opt for 
> a. Removing support for Heartbeat from Pacemaker
> b. Switching to Pacemaker 1.1.9 or later + Corosync 2
> c. Providing DebConf notices about people breaking their setups
> d. Continue to support crmsh  alongside with PCS
> 
> Any comments are highly appreciated.
> 
> Best regards
> Martin
> 
> -- 
> Martin Gerhard Loschwitz
> Chief Brand Officer, Principal Consultant
> hastexo Professional Services