unit(s) not upgrading packages after changing openstack-origin

[Gabriel Cocenza]

I'm in a cloud upgrading from victoria to wallaby and I noticed that one unit didn't get upgrade after changing the openstack-origin to cloud:focal-wallaby (action-managed-upgrade was set to False).

The unit that didn't upgrade is active idle for some hours and the packages version didn't change:

https://pastebin.canonical.com/p/jf293y3dYV/

If I run `juju run-action barbican/2 openstack-upgrade` then after the unit is stable, the package is upgraded.

The same pattern happened on charm-aodh, so maybe it's a problem with reactive openstack-charms

[Gabriel Cocenza (gabrielcocenza)]

The workaround for ceph-radosgw was manually changing /etc/apt/sources.list.d/cloud-archive.list to wallaby in the leader unit since there is no openstack-upgrade action and pausing and resume was not enough to get the packages upgrade.

[Gabriel Cocenza (gabrielcocenza)]

all units on charm-octavia didn't get upgrade

[Alex Kavanagh (ajkavanagh)]

Hi Gabriel

Did you observe this behaviour on all the charms that you've added to this bug?

* Please could you add charm logs and juju machine logs for all the units of the applications/charms affected, and the rough time *when* the "juju config <app> openstack-origin=cloud:focal-wallaby" was run. This is so we can see when the config-changed hook ran for the units in question.
* Please could provide the version of Juju being used and/or a juju status output

Thanks

[Gabriel Cocenza (gabrielcocenza)]

Hi Alex.

Yes, I've observed this behavior on all charms that I've added.

Isn't enough the juju-status and the sos-report attached of barbican in the bug description?

I didn't collect the logs for other charms because the behavior was very similar.

[Alex Kavanagh (ajkavanagh)]

Hi Gabriel

No, to understand what's going on the units' debug logs and the units' juju machine logs along with when the config command is run *is* needed. Anyone debugging this needs to be able to match up when the config command was made, to link it to the machine log which will indicate when the config-changed hook ran to link it to the debug log for that config changed hook. Then it would be possible to rule out whether config-changed didn't run, but whether the value changed from the perspective of the charm, or whether the charm took no action on the changed value.

[Launchpad Janitor (janitor)]

[Expired for OpenStack Placement Charm because there has been no activity for 60 days.]

[Launchpad Janitor (janitor)]

[Expired for OpenStack Octavia Charm because there has been no activity for 60 days.]

[Launchpad Janitor (janitor)]

[Expired for Ceph RADOS Gateway Charm because there has been no activity for 60 days.]

[Launchpad Janitor (janitor)]

[Expired for OpenStack Designate Charm because there has been no activity for 60 days.]