My local turnip deployment sometimes gets itself into a state where the
individual units still have IPv6 addresses but no IPv4 addresses (until
I run `systemctl restart systemd-networkd.service` on each of them
manually). This has the very annoying consequence of getting the turnip
charm hooks badly wedged, because they try to mount the NFS storage
volume using its IPv6 address without using the correct literal address
syntax.
While the units losing their IPv4 addresses is probably a bug somewhere
else, it makes sense to handle mounting over IPv6 anyway, and it makes
it much less difficult to recover from this situation.
reactive/ols.py:upgrade_charm
clears ols.service.installed, ols.configured, service.configured
reactive/ols.py:install_service
unpacks new payload; sets ols.service.installed
reactive/ols.py:handle_config_changes
clears ols.configured, service.configured
reactive/ols.py:update_payload
clears ols.service.installed, ols.configured, service.configured
reactive/launchpad-admin.py:configure
crashes because `production-configs/launchpad-db-lazr.conf` doesn't
exist yet in the new unpacked payload
`update_payload` clearing `ols.service.installed` results in some
redundant work, but that's not a serious problem. The problem here is
that the `launchpad.db.configured` flag is still set at the point when
the dispatch logic decides whether to invoke `launchpad-admin`'s
`configure` handler; as a result, it may do so almost immediately after
unpacking the new payload rather than carefully working its way back up
the stack of layers, configuring `launchpad-payload`, then
`launchpad-base`, then `launchpad-db`.
I think the least bad workaround for this is to observe that
`charms.reactive.bus.dispatch` documents that all `@hook` handlers are
invoked first. We can therefore add a few `@hook` handlers that clear
flags for each layer, and thereby ensure that things go in the right
order when upgrading a charm and changing its build label at the same
time.
turnip-base: Avoid comma in Nagios service description
On production, the comma caused Nagios to fail to parse the collected
configuration with errors such as:
Error: Could not find a service matching host name 'lp-prodstack-git-juju-f2a69b-prod-launchpad-git-17' and description 'Git E2E git://git.launchpad.net/launchpad - hint: check nfs-ganesha.service if all appservers are bad' (config file '/etc/nagios3/conf.d/servicegroups/prompt-critical.cfg', starting on line 2)
Error: Could not expand member services specified in servicegroup (config file '/etc/nagios3/conf.d/servicegroups/prompt-critical.cfg', starting on line 2)
Add interface to publish Apache virtual host configuration
This implements the interface described under "Using the vhost-config
relation" in https://git.launchpad.net/apache2-charm/tree/README.md. It
will allow us to put the desired Apache frontend configuration in the
corresponding service charm and then just add some relations to make
everything work. I have a functioning prototype of this for the
librarian.
This interface has 2 main goals:
- Set the `<interface>.available` and `<interface>.configuration.available` flags within the charms
- Send configuration data from the upload processor to the txpkgupload using `set_config()` in `provides.py`, and fetching it from the txpkgupload charm directly once the `<interface>.configuration.available` flag is on.
