openstack/charm-guide
Code Issues Proposed changes
Files
master
charm-guide/doc/source/release-notes/2104.rst
Peter Matulis 45fb20b14e Remove CDG redirects 
This is a doc maintenance task.

Use local links instead of using the redirects that
are configured in the Deploy Guide (due to pages that
were migrated to this current guide). This includes links
implemented via the intersphinx plugin (i.e. cdg:****)

Change-Id: Ieb2607c4cd89a241c377da1808286b80b06bb93e
2022-09-28 16:40:40 -04:00

11 KiB
Raw Permalink Blame History

21.04

Summary of changes

Overview

The 21.04 OpenStack Charms release includes updates for the charms described on the ../project/openstack-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 ../project/release-schedule.

General charm information is published in the OpenStack Charm Guide (this guide) which ultimately supersedes Release Notes contents.

Important

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 src/tests/bundles 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-out and 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: update-ring.

When a clustered application (working alongside the hacluster application) is scaled down (i.e. remove-unit) nodes in the corosync ring will not be removed. The 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: remove-from-cloud and register-to-cloud.

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 register-to-cloud 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: node-name.

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: list-compute-nodes.

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: use-internal-endpoints.

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:

  • neutron-gateway
  • neutron-openvswitch
  • ovn-central
  • ovn-chassis
  • ovn-dedicated-chassis
  • rabbitmq-server

See the Deferred service events page in the OpenStack Charms Deployment Guide for more information.

nova-cloud-controller charm: sync compute availability zones

The nova-cloud-controller charm has a new action: sync-compute-availability-zones.

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

Magnum 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.

Manila charms

Two new tech-preview charms are added to the current list of Manila charms:

Manila is OpenStack's shared filesystem service.

Informational notices

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.

Deprecation notices

hacluster charm: option 'stonith_enabled'

The 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.

Removed features

RabbitMQ Ceph relation

The 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 enable-hardware-offload, enable-sriov and 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:

  1. Changing the number of VFs on a running system breaks connectivity to any running virtual machines.
  2. 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

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.

Note that charm upgrades and OpenStack upgrades are functionally different. For instructions on performing the different upgrade types see Upgrades overview in the OpenStack Charms Deployment Guide.

View Git Blame Copy Permalink