[Debian-ha-maintainers] Debian HA <-> Ubuntu HA sync & help

[Valentin Vidić]

On Thu, Oct 31, 2019 at 02:43:29PM -0300, Rafael David Tinoco wrote:
> This is Rafael, I'm an ubuntu server developer. I'm currently
> syncing/merging HA packages into ubuntu-next (20.04), its the beginning of
> our merge window and I wanted to check out what is the best way for me to
> help the HA maintainers.

Hi Rafael, nice to meet you. I'm one of the maintainers on the Debian side.

> Would it be okay just to do merge requests through salsa ? Is there a list
> of things you would like to be done, possibly with priorities ? I'm also
> thinking in expanding some of the existing DEP8 tests during those merges.

Salsa should probably be the best way, unless it is something that
needs to go to upstream. I don't think there is some list other than
keeping things updated and working. We probably need to cleanup python2
from some packages, but after that it's just testing like you suggested.

> # possible upstream syncs:
> 
> corosync (unstable to v3.0.2-23-g721c5d4b)
> pacemaker (unstable to - 2.0.3-rc1 or 2.0.2)
> ocfs2-tools (unstable to ocfs2-tools-1.8.6-4-g8b3dad1d)
> crmsh (unstable to 4.1.0-37-g6f2c8ea9)

Usually we wait for stable versions in these.

> resource-agents (ubuntu sync to unstable 4.4.0-1)
> pcs (unstable to 0.10.3-46-g170b06cb OR 0.10.3)

These are already updated in unstable.

> drbd-utils (unstable from v9.5.0-1 to v9.11.0)
> keepalived (unstable from v2.0.10-1 to v2.0.19)

Different people work on these two so you might need to contact them
directly.

> OBS: of course I know there isn't the need or the will to update to latest
> upstream, but, sometimes might be wanted by you, I'm not sure if it would.

Right, we usually don't take git versions as things are relatively
stable now. Exceptions are a few packages that don't have releases for
a long time.

> I'm also creating HA documentation for our manuals, maybe, if you're okay, I
> could it for Debian and then just wrap it into the ubuntu manual (this way
> documentation delta is minimized). Idea is to adapt clusters from scratch to
> "supported  deployments" (appropriate # of nodes / fencing / stonith /
> quorum devices) and examples.

I think this is a good plan. Start testing and documenting various
setups while trying to fix problems that you find in the process.
For example LVM-activate is a popular agent for shared storage and
it had some changes in the last year so it would be good to test it
some more.

> Our idea is to keep "pcs" tool as the default tool for our documentation,
> using it on all examples of the "manual" to be created.

In pcs you can maybe test cluster setup since cluster installation
sometimes has RHEL specific parts that don't work as expected on Debian.

> At the end, idea here is just a major "can I help ?! if yes, where ?!" heads
> up, and to inform I'll be dedicating a good part of my time to HA packages
> for in ubuntu, and thought I could do the same for the community.

Since HA is complicated, testing and documenting various setups would be
good indeed. You can probably focus on resource-agents and fence-agents
since they change more and sometimes have small problems like bashisms
that break the agents from working on Debian/Ubuntu. If you fix a
problem and send it to upstream we get the fix in the next release too :)

-- 
Valentin