Comment 6 for bug 2007587
Revision history for this message
| Alex Kavanagh (ajkavanagh) wrote Re: Upgrading vault from charmstore stable to 1.7/stable fails | #6 |
© 2004
Canonical Ltd.
•
Terms of use
•
Data privacy
•
Contact Launchpad Support
•
Blog
•
Careers
•
System status
•
bbfa235
(Get the code!)
For future travellers:
Pre charmhub, upgrade-charm never had the possibility of changing the snap channel; that was done via config changed.
For charmhub charms, however, charm-upgrade can take two forms:
* an 'in channel' refresh where just the charm is upgraded, but no channel is switched.
* a 'change channel' refresh where the charm is changed AND the channel is switched.
The issue with the 2nd one is that the defaults for the config items *may* change; in this case the default snap channel changes with the charm channel, and this causes a snap refresh.
The issue here is that restarting vault will seal the unit, and if all the units are sealed (e.g. during a charm refresh that change the channel and the default is being used), then the whole vault application will become sealed which would almost certainly cause a control plane outage of the vault using apps (e.g. on OpenStack, OVN and the api charms).
What we may want to do is to detect the change in the default config (snap version) but not actually do the refresh, but instead put something on the status line and enter the blocked state to indicate that the default version for the charm and the installed version are different - this won't happen with a user configured version as that won't change during the refresh.
Then to resolve this situation each unit could be refreshed, and then unsealed, progressively, preventing the outage.