Summary of changes¶
- New charm features
- Informational notices
- Deprecation notices
The 21.04 OpenStack Charms release includes updates for the charms described on the Charms page. As of this release, the project consists of 60 supported (stable) charms.
For the list of bugs resolved in this release refer to the 21.04 milestone in Launchpad.
For scheduling information of past and future releases see the Release schedule.
General charm information is published in the OpenStack Charm Guide (this guide) which ultimately supersedes Release Notes contents.
Always upgrade to the latest stable charms before making any major changes to your cloud and before filing bug reports. Refer to section Upgrading charms below for details.
New charm features¶
With each new feature, there is a corresponding example bundle in the form of a
test bundle, and/or a section in the OpenStack Charms Deployment Guide, that
details its usage. Test bundles are located in the
directory of the relevant charm repository (see all charm repositories).
ceph-osd charm: marking individual OSDs as ‘out’ or ‘in’¶
The ceph-osd charm actions
osd-in can now target individual
OSD volumes. The previous behaviour was to act on all volumes - there is a new
keyword ‘all’ for that use case. For example:
juju run-action --wait ceph-osd/0 osd-out osds=osd.0,osd.1 juju run-action --wait ceph-osd/1 osd-out osds=all
hacluster charm: scaling down¶
The hacluster charm has a new action:
When a clustered application (working alongside the hacluster application) is
scaled down (i.e.
remove-unit) nodes in the corosync ring will not be
update-ring action performs the removal and updates the
corosync configuration accordingly. Failure to run this action will leave the
cluster in an “incomplete” state. The corosync ring does not need to be updated
when scaling up; it is automatically extended. See the hacluster charm
README for more information.
nova-compute charm: scaling down¶
The nova-compute charm has two new actions:
These actions assist with the downscaling of a nova-compute cluster. The
remove-from-cloud action unregisters a Compute service from the cloud and
is run prior to unit removal (
juju remove-unit). This ensures that “dead”
services do not linger at the OpenStack level. The
action allows the operator to revert the process by re-registering the service
(providing unit removal has not been made). See the nova-compute charm
README for more information.
nova-compute charm: query name of compute node¶
The nova-compute charm has a new action:
This action prints the node name of the nova-compute unit it is run against.
nova-compute charm: list compute nodes¶
The nova-compute charm has a new action:
This action prints a list of all compute nodes registered in the cloud.
openstack-dashboard charm: new option ‘use-internal-endpoints’¶
The openstack-dashboard charm has a new configuration option:
Horizon’s default behaviour is to use Keystone’s public endpoint. When this new option is set to ‘true’ Keystone’s internal endpoint will be used instead. This could be used when a cloud’s topology restricts Horizon’s access to the public network.
This option is already available in other charms (e.g. nova-cloud-controller and heat).
Global cap to charm option ‘worker-multiplier’¶
For those charms that provide service workers their number is determined by the
worker-multiplier charm option. There is a maximum number (a “cap”) of four
workers that is applied when the option is not explicitly set. Previously the
cap was enforced only when an application was deployed to a LXD container. With
this new charm release, the cap is always applied.
This new behaviour takes effect upon charm upgrade.
Denying service restarts and hook calls¶
The deferred service events feature can be enabled on a per-charm basis to avoid sudden service interruptions caused by maintenance and operational procedures applied to the cloud.
This feature is currently supported by the following charms:
nova-cloud-controller charm: sync compute availability zones¶
The nova-cloud-controller charm has a new action:
This new action will configure host aggregates in Nova with availability zones of related nova-compute units. This action will add hypervisors to the appropriate host aggregate but will not remove hypervisors from existing host aggregates. The hypervisors are placed into the appropriate availability zone as determined by the nova-compute charm. See Availability Zones in the nova-compute charm README for more information on configuring availability zones for compute services.
This action is supported on OpenStack Stein and newer.
New tech-preview charms¶
Two new tech-preview charms are now available for the deployment of OpenStack Magnum:
Magnum deploys Container Orchestration Engines (COE) such as Kubernetes, Docker Swarm, and Apache Mesos onto OpenStack instances.
Two new tech-preview charms are added to the current list of Manila charms:
Manila is OpenStack’s shared filesystem service.
Trilio charms release cadence¶
The Trilio charms will no longer be released with the same cadence as the other OpenStack charms. Instead, they will be released shortly after releases of the Trilio code. For instance, Trilio 4.1 is due in February and the Trilio charms will be released shortly thereafter.
hacluster charm: option ‘stonith_enabled’¶
stonith_enabled configuration option for the hacluster charm is
deprecated and will be removed in the next release of the OpenStack Charms.
Resource fencing (aka STONITH) is now always enabled for every node in the
cluster. See bug LP #1881114 and What is STONITH? for more details.
RabbitMQ Ceph relation¶
ceph relation in the rabbitmq-server charm is deprecated and will be
removed in the 21.04 charm release. The relation exists to support an obsolete
method of RabbitMQ clustering which involved sharing queue data between the
units using RBD volumes.
Runtime configuration of SR-IOV and acceleration¶
The Neutron Open vSwitch and OVN charms will no longer perform runtime configuration of SR-IOV Virtual Functions (VFs) or hardware acceleration.
Changes made to configuration options
sriov-numvfs must be followed by a reboot of any
neutron-openvswitch or ovn-chassis units in order for the changes to take
effect. This is true regardless of when the changes were made (i.e. at
deploy-time or post-deploy).
This change of charm behaviour is necessary for two reasons:
Changing the number of VFs on a running system breaks connectivity to any running virtual machines.
For Hardware acceleration support there is a particular order in which components of the system must be set up for successful operation. Applying or changing the configuration at runtime would involve operations like removing and re-applying host network configuration, and could also lead to NIC firmware malfunction. As such, runtime application of configuration changes for the above mentioned configuration options falls outside the domain of what the charms can control.
Upgrading charms will making available new features and bug fixes. However, the latest stable charm revision should also be used prior to making any topological changes, application migrations, workload upgrades, or series upgrades. Bug reports should also be filed against the most recent revision.