[Debian-ha-maintainers] state of debian-ha

[Ferenc Wagner]

Arturo Borrero Gonzalez <arturo.borrero.glez at gmail.com> writes:

> I think it worth pushing pacemaker to unstable as soon as possible so
> people can start testing the stack and reporting bugs.

Agreed.  One thing keeping back the Pacemaker package is the licensing
of its documentation.  It's GFDL, so we should check that it does not
contain invariant sections.  I don't know how to do that, though.

Also, its upstream systemd service file contains

Restart=on-failure

which I'm inclined to remove on the grounds that if Pacemaker fails, the
node will get fenced anyway, so restarting it just adds noise to the
logs (I'm investigating such an event in our test cluster right now).

Some comment cleanup would probably also be useful, for example I don't
get the fuss around crm_mon and stopping corosync, to mention two...

> Apart of that, there are other related packages which might need some
> work (or decisions) as well: redhat-cluster, sheepdog, crmsh,
> heartbeat, etc..

Anybody knows a reason not to drop redhat-cluster?
Sheepdog builds with Corosync 2 with minimal changes.
AFAIK crmsh uses the Pacemaker interface only, so it isn't affected by
the corosync transition.
I don't think there would be much point in keeping heartbeat, but if we
do, it must be an alternative dependency of Pacemaker.

Once we've uploaded Pacemaker, DLM can follow without problems, and
after that clvm can be fixed.

I haven't tested building GFS2 yet, but it's actively maintained, so it
should work.

On the other hand, the OpenAIS package could go.  I'm not sure it's even
able to use Corosync 2, upstream development stopped years ago AFAIK.

So, if somebody could help cleaning up the Pacemaker legalities, that
would be most helpful to get things moving again.  I've got a security
issue to handle in another package stack, but expect to get back to
working on Pacemaker shortly.
-- 
Regards,
Feri.