OpenStack upgrade advice around subordinates and principle charms needs to be updated

[Alex Kavanagh]

Due to the nature of tracks on charmhub and how a charm on a track only officially supports that track's OpenStack release and the previous one (or in the case of Caracal, Antelope (2023.1) the SLURP) release, there needs to be advice added on what to do with subordinate charms.

The issue, is that cinder-ceph (a subordinate) actually checks the OpenStack version (which it probably shouldn't) via the packages installed on the system, and if the principle (in this case) cinder is upgraded from yoga -> zed, then the cinder-ceph (at yoga) breaks.

Although there are a couple of issues at play here, particularly around isolation of subordinates, that ship has largely sailed.

I think the general advice that should be added to the charm-guide is that OpenStack subordinate charms (i.e. not support charms) should have their track switched to the next version before the principle charm. As the (in this case zed) charm will support yoga, this should not cause any issues and code paths that check packages against versions will still work.

Action:

 1. add advice to charm-guide that subordinate charms should be upgraded to the next OpenStack version (or SLURP release) before the principle charm.

[Jadon Naas (jadonn)]

Upgrading the subordinate charms to the next release before upgrading their principle charms sounds like a reasonable approach to me.

[Samuel Allan (samuelallan)]

What's the expected upgrade pattern for refreshing charms to the next release channel and actually doing the workload upgrade?

```
juju refresh X --channel zed/stable
juju config X openstack-origin=cloud:jammy-zed
juju refresh Y --channel zed/stable
juju config Y openstack-origin=cloud:jammy-zed
juju refresh Z --channel zed/stable
juju config Z openstack-origin=cloud:jammy-zed
```

vs

```
juju refresh X --channel zed/stable
juju refresh Y --channel zed/stable
juju refresh Z --channel zed/stable
juju config X openstack-origin=cloud:jammy-zed
juju config Y openstack-origin=cloud:jammy-zed
juju config Z openstack-origin=cloud:jammy-zed
```

I just want to be clear on definitions here, since upgrading can refer to upgrading the charm code (via juju refresh) or upgrading the workload (via updating openstack-origin).

[Alex Kavanagh (ajkavanagh)]

Also, note this bug (https://github.com/canonical/charmed-openstack-upgrader/issues/466) is affected by the issue.

[Alex Kavanagh (ajkavanagh)]

My comment from: https://github.com/canonical/charmed-openstack-upgrader/issues/466#issuecomment-2230931757

The general approach would be, for a single machine.

a) Make sure all the charms are up to date for their channel first. `juju refresh`
b) Make sure that openstack-origin/source is pointing to the current version (i.e. is not the 'default' unset state).
c) Switch charms to the next channel (subordinates and principles) - `juju switch`
d) Switch the openstack-origin/source of the principle charms `juju config` (and perhaps `juju run ... openstack-upgrade`.

This would ensure the best chance of success. I think with this approach, any errors are then a bug that should be fixed.