Charm delivery¶
Overview¶
Juju charms are delivered via the online Charmhub. This page provides charm delivery information in the context of the OpenStack Charms project.
There are two general types of OpenStack charms: one that does use channels and one that does not (legacy) - see the Charm types for details. This page will focus on channel charms.
Channels¶
The notion of channels is central to the delivery of the correct OpenStack charm.
By definition, a channel is comprised of three components: track, risk level, and branch. If a component is not specified at deploy time a default value will be used.
Unlike many charms in the Charmhub, the OpenStack Charms project leverages tracks extensively in order to manage a different array of supported charm versions for each supported combination of OpenStack release and Ubuntu series.
The Charmhub can be queried for a charm’s supported channels. For utmost clarity, this should be done on a per-series basis. For example, to query the channels for the glance charm on the ‘focal’ series:
juju info --series focal glance
Alternatively, the Charmhub web site can be visited: https://charmhub.io/glance
Important
For deployments that are running non-channel (legacy) charms, please see special charm operation All charms: migration to channels.
Tracks¶
A charm’s track corresponds to a given release of its payload. When the associated upstream project uses well-known release names, the track will use that name as its version number. Otherwise, the track’s name will typically be based on a version number or a release date. For example:
Charm |
Example tracks |
|---|---|
nova-compute |
wallaby, xena |
ceph-mon |
octopus, pacific |
rabbitmq-server |
3.8, 3.9 |
ovn-central |
22.03, 22.09 |
latest track¶
Generally speaking, the latest track is a special track whose purpose is to
conveniently point to the latest version of a piece of software.
Warning
The OpenStack Charms project strongly advises against the use of the
latest track due to its implicit nature. In doing so, a future charm
upgrade may result in a charm version that does not support your current
OpenStack release.
Risk levels¶
There are four risk levels that are potentially available for any track:
edge, beta, candidate, and stable. Charms will be promoted
through these levels based on the OpenStack Charms team policy on software
maturity.
Branches¶
There is the possibility for a further subdivision of tracks and risk levels into Charmhub “branches”, which are meant to provide short-lived releases (e.g. quick bug fix).
Tracks for the OpenStack Charms project¶
Note
The information in this section will be updated as new tracks become available.
This section shows the recommended tracks for all the main charms that make up the OpenStack Charms project. The information is categorised by the Ubuntu release/series running on the cloud nodes.
Important
Recall that the target OpenStack release is identified by the track associated with the OpenStack service charms (top row in each table).
A track can be specified during the deployment of an initial application or during an OpenStack service upgrade. See the below section Delivering a charm for details.
Charms |
Tracks |
|
|---|---|---|
OpenStack charms |
|
|
Ceph charms |
|
|
OVN charms |
|
|
MySQL charms |
|
|
hacluster |
|
|
pacemaker-remote |
|
|
rabbitmq-server |
|
|
vault |
|
|
Charms |
Tracks |
||||
|---|---|---|---|---|---|
OpenStack charms |
|
|
|
|
|
Ceph charms |
|
|
|
|
|
OVN charms |
|
|
|
|
|
MySQL charms |
|
|
|
|
|
hacluster |
|
|
|
|
|
pacemaker-remote |
|
|
|
|
|
rabbitmq-server |
|
|
|
|
|
vault |
|
|
|
|
|
Charms |
Tracks |
||||
|---|---|---|---|---|---|
OpenStack charms |
|
|
|
|
|
Ceph charms |
|
|
|
|
|
pacemaker-remote |
|
|
|
|
|
percona-cluster |
|
|
|
|
|
hacluster |
|
|
|
|
|
rabbitmq-server |
|
|
|
|
|
vault |
|
|
|
|
|
Provider-specific subordinate charms¶
Some services interact with provider-specific subordinate charms in order to enable a specific SDN, storage plugin, etc. Although these are considered supporting charms, they nonetheless often enable specific functionality for an OpenStack service. They therefore follow the same track-naming schema as do the OpenStack service charms.
This is the list of provider-specific subordinate charms:
cinder-ceph
cinder-lvm
cinder-netapp
cinder-purestorage
neutron-openvswitch
neutron-api-plugin-arista
neutron-api-plugin-ironic
neutron-api-plugin-ovn
keystone-saml-mellon
Delivering a charm¶
A channel charm gets delivered by using the --channel option with either
the deploy or refresh commands. See also the
Software sources page.
Deploying a charm¶
To deploy a channel charm select the channel that corresponds to the target OpenStack release.
Examples,
To deploy the placement charm for an OpenStack Xena cloud the ‘xena/stable’ channel is chosen:
juju deploy --channel xena/stable placement
To deploy the ceph-mon charm for an OpenStack Xena cloud the ‘quincy/stable’ channel is chosen:
juju deploy --channel quincy/stable ceph-mon
Changing the channel¶
A charm’s channel is typically changed as part of an OpenStack upgrade. The new channel must be chosen according to the target future OpenStack release.
Warning
Changing a charm’s channel will trigger a charm upgrade, which will typically cause the underlying cloud service to restart.
Study the OpenStack upgrade process prior to changing charm channels.
Examples,
To change the channel for the vault charm when upgrading to OpenStack Yoga the channel should be changed to ‘yoga/stable’:
juju refresh --channel 1.7/stable vault
To change the channel for the ovn-central charm when upgrading to OpenStack Yoga the channel should be changed to ‘22.03/stable’:
juju refresh --channel 22.03/stable ovn-central
