All charms: migration to channels¶
All maintenance for stable charms occurs on the various explicitly-named
channels (i.e. not based on the
latest track). These are the channels that
the charms must be migrated to.
In order to receive charm updates (e.g. bug fixes) it is highly recommended to migrate from legacy non-channel charms to charms that use a channel.
See Charm delivery for an overview of how OpenStack charms are distributed.
All charms are now served from the Charmhub, regardless of which prefix
ch:) is used to deploy charms.
Determine current versions¶
A charm’s channel is selected based on its corresponding service’s software version. Use the information in the below two sub-sections to determine the version running for each application in your deployment.
OpenStack service charms¶
For OpenStack service charms, to get the running OpenStack version you can
inspect the value assigned to the
openstack-origin charm configuration
For example, if the juju config keystone openstack-origin command outputs ‘focal-xena’ then the running OpenStack version is Xena.
It is expected that all OpenStack service charms will report the same OpenStack version.
All other charms¶
For all other charms, utilise the juju status command.
App Version Status Scale Charm Store Channel Rev OS Message rabbitmq-server 3.8.2 active 1 rabbitmq-server charmstore stable 117 ubuntu Unit is ready
RabbitMQ is running version
App Version Status Scale Charm Store Channel Rev OS Message ceph-osd 16.2.6 active 3 ceph-osd charmstore stable 315 ubuntu Unit is ready (2 OSD)
Ceph is running version
Since the Ceph channels are based on code names, as a convenience, a mapping of versions to code names is provided:
Select the channels¶
The Charm delivery page includes a list of all the tracks available to the OpenStack charms.
if Ceph Octopus is running, then any Ceph charm that supports the
octopus/stablechannel should use that channel
if OVN 20.03 is running, then any OVN charm that supports the
20.03/stablechannel should use that channel
if RabbitMQ 3.8.2 is running, then the rabbitmq-server charm should use the
Based on this information, select the appropriate channel for each charm in your deployment.
Upgrade every Juju component of the given deployment to Juju
includes the Juju client, the controller model, and the workload model. See the
Juju upgrade documentation for guidance.
Perform the migration¶
The migration consists of replacing all charms with new but software-equivalent charms. Technically, this is not an upgrade but a form of crossgrade.
There is no need to upgrade the current charms to their latest stable revision prior to the migration.
The charm of a currently-deployed application is migrated according to the following syntax:
juju refresh --switch ch:<charm> --channel <channel> <application-name>
For example, if the selected channel for the rabbitmq-server charm is
juju refresh --switch ch:rabbitmq-server --channel 3.8/stable rabbitmq-server
The application argument represents the application as it appears in the model. That is, it may be a named application (e.g. ‘mysql’ and not ‘mysql-innodb-cluster’).
Change operator behaviour¶
Once all of your deployment’s charms have been migrated to channels it is important to:
stop using the
cs:prefix when referencing charms, whether in bundles or on the command line. Use the
ch:prefix instead. Note that Juju
ch:prefix by default on the command line.
always specify a channel when deploying a charm (e.g. juju deploy --channel pacific/stable ceph-radosgw)