OpenStack upgrade advice around subordinates and principle charms needs to be updated
| Affects | Status | Importance | Assigned to | Milestone | |
|---|---|---|---|---|---|
| OpenStack Charm Guide |
Triaged
|
High
|
Unassigned | ||
Bug Description
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) wrote | #1 |
| Changed in charm-guide: | |
| status: | New → Triaged |
| importance: | Undecided → High |
| Samuel Allan (samuelallan-deactivatedaccount) wrote | #2 |
| Alex Kavanagh (ajkavanagh) wrote | #3 |
| Alex Kavanagh (ajkavanagh) wrote | #4 |
Upgrading the subordinate charms to the next release before upgrading their principle charms sounds like a reasonable approach to me.