This is incomplete. It has two major known problems:
* lp-mailman currently wants to write its configuration on startup.
This is difficult to disentangle, and it conflicts with the way our
charms usually work where we deploy code as root and start it as a
non-root user. I made an effort to only write configuration if it
differs from the current contents, but this is fragile and I'm not
sure it completely works yet. It may be worth exploring other
approaches too.
* I haven't done anything with email configuration yet. Both inbound
and outbound email are of course vital for lp-mailman.
`kombu` is a higher-level messaging library than `amqp`. For our
purposes, we can treat it mostly as a wrapper for `amqp` with some
slightly more convenient interfaces, but it has one key feature that's
of interest to us: it supports multiple RabbitMQ broker URLs with
round-robin failover between them. This makes it possible to configure
lp-mailman to use RabbitMQ with high availability: if we have a RabbitMQ
cluster, then we can configure lp-mailman with broker URLs for all the
nodes in the cluster, and if one fails then `kombu` will automatically
fail over to the next.
To make it practical to configure this, I had to add a
`rabbitmq.broker_urls` configuration option, which supersedes the
existing broken-out configuration options (`rabbitmq.host`,
`rabbitmq.userid`, `rabbitmq.password`, and `rabbitmq.virtual_host`).
For backward compatibility, the old options continue to work as long as
`rabbitmq.broker_urls` is unset.
This also includes upgrading to oops-amqp 0.2.0, since that includes a
change to accept connection factories that return `kombu` connections.
This is a reduced version of https://code.launchpad.net/~cjwatson/launchpad/+git/launchpad/+merge/432065
in Launchpad, picked up when I realized that it was going to be needed
by the lp-mailman charm. Testing is difficult since we stripped out
much of the supporting code when extracting lp-mailman from Launchpad,
but at least similar code is already tested as part of Launchpad.
The tarball we were building omitted the actual Mailman code, and so
failed to build on deployed systems; it was also constructed in such a
way that we ended up trying to pull the dependencies repository again
unnecessarily. This change produces tarballs that we can actually
deploy.
The upcoming charmed redeployment will use bionic. (charmcraft doesn't
support xenial, and focal doesn't support enough of Python 2 for
lp-mailman, so bionic is the usable sweet spot for now.)
