openstack
/
charm-guide
Code Issues Proposed changes
charm-guide/doc/source/1910.rst

16 KiB
Raw Blame History

19.10 (DRAFT)

Summary

The 19.10 OpenStack Charms release includes updates for the following charms. Additional charm support status information is published in the OpenStack Charm Guide which ultimately supersedes Release Notes contents.

Always use the latest stable charm revision before proceeding with topological changes, application migrations, workload upgrades, series upgrades, or bug reports.

Supported Charms

  • aodh
  • barbican
  • barbican-vault
  • ceilometer
  • ceilometer-agent
  • ceph-mon
  • ceph-osd
  • ceph-proxy
  • ceph-radosgw
  • ceph-rbd-mirror
  • cinder
  • cinder-ceph
  • cinder-purestorage
  • designate
  • designate-bind
  • glance
  • gnocchi
  • hacluster
  • heat
  • keystone
  • keystone-ldap
  • lxd
  • neutron-api
  • neutron-openvswitch
  • neutron-gateway
  • neutron-dynamic-routing
  • nova-cloud-controller
  • nova-compute
  • octavia
  • openstack-dashboard
  • percona-cluster
  • placement
  • rabbitmq-server
  • swift-proxy
  • swift-storage
  • vault

Preview Charms

  • barbican-softhsm
  • ceph-fs
  • cinder-backup
  • keystone-saml-mellon
  • manila
  • manila-generic
  • masakari
  • masakari-monitors
  • mysql-innodb-cluster
  • mysql-router
  • pacemaker-remote
  • tempest

Removed Charms

n/a

New Charm Features

With each new feature, there is a corresponding example bundle in the form of a test bundle, and/or a OpenStack Charms Deployment Guide section which details the use of the feature. For example test bundles, see the src/tests/bundles/ directory within the relevant charm repository.

OpenStack Train

The 19.10 OpenStack Charms release introduces support for OpenStack Train on Ubuntu 18.04 LTS (via UCA) and Ubuntu 19.10.

Please note the placement charm must be deployed and related to the nova-cloud-controller charm as of OpenStack Train. See section Placement Charm for more details.

nova-cloud-controller: instance migration - DNS caching is now the default

Note

This has nothing to do with Designate or Neutron DNS.

The 19.07 release introduced the option to enable caching of DNS lookups of the nova-compute units which are used by nova to perform migrations of tenant instances between nova-compute units. This was not enabled by default. The 19.10 release "flips the switch" and enables this option by default so that after upgrade, if the option was not explicitly set, DNS results will be cached automatically. New clouds will also, unless the option is explicitly set to false, cache DNS host lookups.

The reason for caching DNS host lookups is to reduce the time to add nova-compute units to an existing cloud, or during first deployment.

Please see the config option cache-known-hosts on the nova-cloud-controller charm for further details.

Policy Overrides

The Policy Overrides feature provides operators with a mechanism to override policy defaults on a per-service basis.

Policy defaults for an OpenStack service are defined via "policy-in-code" and/or via a default policy YAML file provided by the charm. The operator can use the new feature by providing a ZIP file consisting of at least one YAML file which contains policy rules that the service will observe when responding to API queries. This allows operators to selectively override the default policies of that service.

This feature is being provided in the following charms:

  • cinder
  • designate
  • glance
  • keystone
  • neutron-api
  • nova-cloud-controller

For further details consult appendix Policy Overrides in the OpenStack Charms Deployment Guide.

Please consult the README for each charm to determine exactly what is provided with respect to this feature.

Ceph Nautilus

Along with OpenStack Train, the 19.10 charm release includes support for the Nautilus release of Ceph.

Ceph Placement Group Autotuning

In Ceph Nautilus, the OpenStack Charms now support autotuning of placement groups. The new pg_autoscaler module allows the cluster to consider the amount of data stored, or expected, in each pool and manage the correct pg_num values automatically.

This feature can be disabled entirely by setting a new configuration option, pg-autotune, to "false". This option defaults to "auto" which will cause new deployments on Ceph Nautilus to enable the autoscaler, but older releases upgraded to Nautilus will need to explicitly opt-in by setting pg-autotune to "true".

Neutron Port Forwarding

Neutron Port forwarding extension can now be optionally enabled with 19.10 charms for OpenStack Rocky and later. Be aware that the Train openstack-client version (or later) may be required in order to interact with the feature from the command line.

For more information on this feature see the Neutron documentation.

Migration to FQDN for agent registration

Starting with the 19.10 charms when deploying OpenStack Stein or newer, the Nova Compute agent as deployed by the nova-compute charm and Neutron agents as deployed by the neutron-openvswitch charm will use a fully qualified domain name (FQDN) when registering with the API services.

As the name an agent registers with is referenced across multiple services in a OpenStack cloud this change will only apply to newly deployed units. Upgrading the above two charms or upgrading OpenStack will not trigger the new behaviour.

The backdrop of the change is:

  • Fix bugs in third party services relating to consistency of hypervisor naming in Nova.
  • Avoid deploy time issues in the event a node is configured without a search domain, and also support clouds with a segregated DNS layout.
  • Switch to a more sensible default mode of operation enabling easier integration with new technologies such as OVN.

Ceph RADOS Gateway tenant namespacing

The ceph-radosgw charm now supports deployment with tenant namespaces. This is enabled during initial deployment using the namespace-tenants configuration option. Enabling this option post deployment will have no effect as it is not possible to migrate a deployment without tenant namespacing to one with tenant namespacing enabled.

Endpoint URLs for object storage will contain the tenant ID in the form:

http://<cephradosgw-unit-ip-or-vip>:80/swift/v1/AUTH_<tenant-id>

This feature allows per-tenant bucket namespaces, rather than a global bucket namespace, which is aligned to the behaviour of OpenStack Swift.

Placement Charm

The 19.10 OpenStack Charms release introduces a new charm for the placement API. The placement API service was extracted from the Nova project in OpenStack Train and moved to its own project. Therefore, the new placement charm must be deployed and related to the nova-cloud-controller charm for OpenStack Train deployments. See section Upgrading OpenStack for more details on how to introduce the placement charm into existing deployments when upgrading to OpenStack Train.

Cinder Integration with Pure Storage Array

The 19.10 OpenStack Charms release introduces a new charm which can be used to integrate cinder with a Pure Storage array. To use the new subordinate charm:

juju deploy cinder
juju deploy cinder-purestorage
juju add-relation cinder-purestorage cinder

The cinder-purestorage charm needs to be configured with the IP address of the storage array and provided with an API token for authentication. Typically the settings that need configuring are:

protocol: iscsi
volume-backend-name: cinder-pure
san-ip: PURESTORAGE_IP
pure-api-token: API_TOKEN

Preview Charm Features

mysql-innodb-cluster and mysql-router

The 19.10 OpenStack Charms release introduces two new charms to deploy MySQL 8 for OpenStack: mysql-innodb-cluster and mysql-router.

The mysql-innodb-cluster charm deploys MySQL 8 in an InnoDB cluster with a read/write node and N number of read-only nodes.

The mysql-router charm deploys MySQL 8 mysqlrouter which will proxy database requests from the principle charm application to a MySQL 8 InnoDB Cluster. MySQL Router handles cluster communication and understands the cluster schema.

A simple example deployment:

juju deploy cs:keystone
juju deploy cs:~openstack-charmers-next/mysql-router
juju deploy -n 3 cs:~openstack-charmers-next/mysql-innodb-cluster
juju add-relation mysql-router:db-router mysql-innodb-cluster:db-router

Upgrading charms

Always use the latest stable charm revision before proceeding with topological changes, charm application migrations, workload upgrades, series upgrades, or bug reports.

Please ensure that the keystone charm is upgraded first.

To upgrade an existing deployment to the latest charm version simply use the upgrade-charm command. For example:

juju upgrade-charm keystone

Charm upgrades and OpenStack upgrades are functionally different. Charm upgrades ensure that the deployment has the latest charm revision, containing the latest charm fixes and charm features available for that deployment, whereas OpenStack upgrades influence the software package versions of OpenStack itself.

Charm upgrades do not trigger OpenStack upgrades. However, OpenStack upgrades do require the latest charm version as pre-requisite.

Upgrading OpenStack

Note

Upgrading an OpenStack cloud is not without risk; upgrades should be tested in pre-production testing environments prior to production deployment upgrades.

See appendix OpenStack Upgrades in the OpenStack Charms Deployment Guide for more details.

Before upgrading OpenStack, all OpenStack Charms should be running the latest stable charm revision.

To upgrade an existing Stein-based deployment on Ubuntu 18.04 to the Train release, re-configure the charm with a new openstack-origin configuration. For example:

juju config nova-compute openstack-origin=cloud:bionic-train

As of Train, the placement API is managed by the new placement charm and is no longer managed by the nova-cloud-controller charm. The upgrade to Train therefore requires some coordination to transition to the new API endpoints.

Prior to upgrading nova-cloud-controller to Train, the placement charm must be deployed for Train and related to the Stein-based nova-cloud-controller. It is important that the nova-cloud-controller unit leader is paused while the API transition occurs (paused prior to adding relations for the placement charm) as the placement charm will migrate existing placement tables from the nova_api database to a new placement database. Once the new placement endpoints are registered, nova-cloud-controller can be resumed.

Here's an example of the steps just described:

juju deploy --series bionic --config openstack-origin=cloud:bionic-train cs:placement
juju run-action nova-cloud-controller/leader pause
juju add-relation placement mysql
juju add-relation placement keystone
juju add-relation placement nova-cloud-controller
openstack endpoint list # ensure placement endpoints are listening on new placment IP address
juju run-action nova-cloud-controller/leader resume

Only after these steps have been completed can nova-cloud-controller be upgraded. Here we upgrade all units simultaneously but see HA with pause/resume in the OpenStack Charms Deployment Guide for a more controlled approach:

juju config nova-cloud-controller openstack-origin=cloud:bionic-train

New Bundle Features

Deprecation Notices

Removed Features

Ceph Nautilus has removed support for directory backed OSDs. The charms will allow for the creation of directory backed OSDs on older Ceph releases but will log a warning about their use from Nautilus onwards. Existing directory backed OSDs will continue to function after an upgrade to Nautilus.

Known Issues

Masakari and Masakari Monitors

Both Masakari charms remain as previews. Bugs LP #1728527 and LP #1839715 need to be resolved in order to arrive at a successful instance HA deployment. Bug LP #1773765 is likely to affect on-going support of a Masakari deployment.

Glance Simplestreams Sync

When deploying the glance-simplestreams-sync charm on Bionic a more recent version of the simplestreams package must be installed by configuring a PPA:

juju config glance-simplestreams-sync source=ppa:simplestreams-dev/trunk

See bug LP #1790904 for details.

Designate and Vault at Ocata and earlier

The Designate charm for OpenStack releases Pike and earlier does not yet support SSL via Vault and the certificates relation. See bug 1839019

Current versions of OpenStack with Vault and the certificates relation are supported by the Designate charm.

Restart Nova services after adding certificates relation

A race condition exists with the use of the 'certificates' relation. When SSL certificates are issued Nova services may attempt to talk to the placement API over HTTP while the API has already changed to HTTPS. See bug 1826382.

To mitigate against this, restart nova-compute and nova-scheduler services once certificates have been issued:

juju run --application nova-compute "systemctl restart nova-compute"
juju run --application nova-cloud-controller "systemctl restart nova-scheduler"

Bugs Fixed

This release includes NNN bug fixes. For the full list of bugs resolved for the 19.10 charms release please refer to the 19.10 milestone in Launchpad.

Next Release Info

Please see the OpenStack Charm Guide for current information.