master : lp:~cjwatson/ols-charm-deps : Git : Code : ols-charm-deps

Get this branch:: git clone -b master https://git.launchpad.net/~cjwatson/ols-charm-deps

Only Colin Watson can upload to this branch. If you are Colin Watson please log in for upload directions.

Branch merges

Branch information

Name:: master

Repository:: lp:~cjwatson/ols-charm-deps

Recent commits

9c59a98... by Colin Watson on 2023-09-08

Only prune payloads if current and desired build labels differ

Merged from https://code.launchpad.net/~cjwatson/ols-charm-deps/+git/ols-layers/+merge/451050

3f624a6... by Colin Watson on 2023-09-08

Only prune payloads if current and desired build labels differ

`install_payload` can sometimes end up being called more than once for
the same build label: in particular, if you upgrade the charm and change
its build label at the same time, then the resulting `upgrade-charm` and
`config-changed` hooks both clear the `ols.service.installed` flag, but
they also both see the new value of `build_label`. As a result, in
`symlink_switch_payload` mode, the second call to `install_payload` can
end up running `prune_payloads` in such a way that it only keeps a
single payload, which means that the previous payload ends up getting
removed much earlier than we'd expect; that can be a problem if
processes are still running from that payload. I've noticed occasional
problems resulting from this in Launchpad deployments, depending on the
extent to which we've batched up changes.

I think the simplest fix is to only prune payloads if the current and
desired build labels differ. That way things will behave sensibly more
or less regardless of what goes on at the reactive state machine level.

f8c3e08... by Ines Almeida on 2023-08-23