Launchpad itself

`kombu` (already used by `celery`) 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 Launchpad to use RabbitMQ with high availability: if we have a
RabbitMQ cluster, then we can configure Launchpad 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.

2738ed6... by Colin Watson on 2022-10-23

Rename IMasterStore to IPrimaryStore

Also `IMasterObject` to `IPrimaryObject`, and some other references to
the "master" database. This is in line with an earlier renaming of the
flavor.

This is long, but the bulk of it was mechanical search-and-replace.
I've run the full test suite to verify it.

31b2837... by Colin Watson on 2022-10-23

Add ability to switch DB role after connecting

Our traditional strategy for deploying database credentials has been to
have a password for each database user we want to use, and to deploy
those to `.pgpass` files on each machine that needs to use each user.
This works, but it's quite manual and cumbersome. With charmed
deployments it gets harder: each `db` relation can only communicate a
single set of credentials, which means that a script server would be
stuck having to have perhaps tens of relations representing the wide
variety of database users that the scripts it runs want to use: as well
as being ugly, I expect this would also make Juju very slow.

The natural approach with the PostgreSQL charm (or when emulating it
using `external-services`) is to set the `roles` attribute on the `db`
relation, which causes the relevant user to be made a member of that set
of roles. The `SET ROLE` SQL command can then switch to that role.

I don't see a straightforward way to make these two strategies entirely
compatible, but it's simple enough to add a configuration flag that
selects which strategy we're using, so I've taken that approach.
`database.set_role_after_connecting` defaults to false which indicates
our traditional strategy; setting it to True causes us to use the `SET
ROLE` command after connecting instead, expecting the session user to
have been made a member of the target role.

c83dbb0... by Patch Queue Manager <email address hidden> on 2022-10-21

Automatic merge from stable up to c0a7730cab18

	docs:0 (build)
	lint:0 (build)
	mypy:0 (build)

Launchpad itself

~andrey-fedoseev/launchpad:uct-import-export-patches

Branch merges

Related source package recipes

Related snap packages

Related charm recipes

Branch information

Recent commits