Charm delivery

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.

Important

For deployments that are running non-channel (legacy) charms, please see special charm operation All charms: migration to channels.

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.

Important

When a channel is not requested at deploy time, the default channel is sourced, which, as of Aug 1, 2023, points to yoga/stable.

Querying

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

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	yoga, zed, 2023.1
ceph-mon	pacific, quincy
rabbitmq-server	3.8, 3.9
ovn-central	22.09, 23.03

Note

Track names for the collection of OpenStack service charms are based on the release names of the upstream OpenStack project. Notably, a rename occurred during the March 2023 release cycle where the expected upstream Antelope release effectively became 2023.1. See the upstream OpenStack Releases page.

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.

It is noteworthy that the OpenStack Charms project no longer uses the latest/stable channel at all.

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.

Ubuntu 22.04 LTS (Jammy)Ubuntu 20.04 LTS (Focal)Ubuntu 18.04 LTS (Bionic)

Charms	Tracks
OpenStack charms	yoga	zed	2023.1	2023.2
Ceph charms	quincy	quincy	quincy	reef
OVN charms	22.03	22.09	23.03	23.09
MySQL charms	8.0	8.0	8.0	8.0
hacluster	2.4	2.4	2.4	2.4
pacemaker-remote	jammy	jammy	jammy	jammy
rabbitmq-server	3.9	3.9	3.9	3.9
vault	1.8	1.8	1.8	1.8

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 is intended to 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