`publisher_parts_dir()` was set as
`config.archivepublisher.run_parts_location`, and is
`/srv/launchpad/publisher-parts`. However, the code that uses this
looks like this:
def find_run_parts_dir(distribution_name, parts):
"""Find the requested run-parts directory, if it exists.""" run_parts_location = config.archivepublisher.run_parts_location
if not run_parts_location:
return None
This means that it's actually trying to look in
`/srv/launchpad/publisher-parts/ubuntu`, which didn't exist.
The layer's configuration is really a bit wrong for this, since strictly
we ought to support multiple distributions with independent
configuration for each. However, for now, hardcoding Ubuntu will do
well enough.
upload-queue-processor: Turn fsroot into a property
The strategy of saving previous values in an instance attribute doesn't
work, because charm hooks are run in separate processes and those values
don't persist. Turn `fsroot` into a property instead so that it's
always retrieved from relation data when needed.
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.
