openstack/charm-deployment-guide
Code Issues Proposed changes

Touchups to page titles and wording

Browse Source 
Update links accordingly.

Driveby formatting fixes.

Change-Id: I578f8099f2de652042a793f43fe7322e0bfb5bba
This commit is contained in:
Peter Matulis
2021-01-04 21:01:20 -05:00
parent 1a86498d4d
commit 7dc973e7df
7 changed files with 148 additions and 155 deletions
Download Patch File Download Diff File Expand all files Collapse all files

58
deploy-guide/source/app-certificate-management.rst
View File

@@ -1,6 +1,6 @@
==================================== =========================
Managing TLS certificates with Vault Managing TLS certificates
==================================== =========================
Overview Overview
-------- --------
@@ -11,16 +11,16 @@ certificate authority to your model. The charms consume the certificates
through the `tls-certificates relation`_ and we do our validation using the through the `tls-certificates relation`_ and we do our validation using the
`Vault charm`_. `Vault charm`_.
Enabling Vault Certificate Management Enabling Vault certificate management
------------------------------------- -------------------------------------
OpenStack charms providing an API service have a new 'certificates' relation. OpenStack charms providing an API service have a new 'certificates' relation.
Adding this relation will trigger the OpenStack charm to request Adding this relation will trigger the OpenStack charm to request
certificates and keys from vault. Once vault has provided these the charm certificates and keys from vault. Once vault has provided these the charm
will install them and switch to listening on https, the catalog will also be will install them and switch to listening on https, the catalogue will also be
updated. updated.
.. code:: bash .. code-block:: none
juju add-relation keystone:certificates vault:certificates juju add-relation keystone:certificates vault:certificates
juju add-relation glance:certificates vault:certificates juju add-relation glance:certificates vault:certificates
@@ -60,11 +60,11 @@ Retrieve CSR from Vault
Run the *get-csr* action against the lead unit of the vault application: Run the *get-csr* action against the lead unit of the vault application:
.. code:: bash .. code-block:: none
$ juju run-action vault/0 get-csr juju run-action vault/0 get-csr
Action queued with id: 0495b6ce-09d8-4e57-8d21-efa13794034a Action queued with id: 0495b6ce-09d8-4e57-8d21-efa13794034a
$ juju show-action-output 0495b6ce-09d8-4e57-8d21-efa13794034a juju show-action-output 0495b6ce-09d8-4e57-8d21-efa13794034a
results: results:
output: |- output: |-
-----BEGIN CERTIFICATE REQUEST----- -----BEGIN CERTIFICATE REQUEST-----
@@ -89,7 +89,6 @@ Run the *get-csr* action against the lead unit of the vault application:
enqueued: 2018-06-07 10:21:13 +0000 UTC enqueued: 2018-06-07 10:21:13 +0000 UTC
started: 2018-06-07 10:21:13 +0000 UTC started: 2018-06-07 10:21:13 +0000 UTC
Retrieve the CSR from the action output and place it in a file, removing any Retrieve the CSR from the action output and place it in a file, removing any
leading whitespace. leading whitespace.
@@ -99,21 +98,21 @@ Sign CSR
The exact command from signing the CSR will depend on the setup of the The exact command from signing the CSR will depend on the setup of the
external CA. Below is an example: external CA. Below is an example:
.. code:: bash .. code-block:: none
openssl ca -config openssl.cnf -extensions v3_intermediate_ca -days 3650 \ openssl ca -config openssl.cnf -extensions v3_intermediate_ca -days 3650 \
-notext -md sha256 -in csr_file -out /tmp/vault-charm-int.pem -batch \ -notext -md sha256 -in csr_file -out /tmp/vault-charm-int.pem -batch \
-passin pass:secretpassword -passin pass:secretpassword
*If the signing is rejected due to mismatched O or OU or C etc then rerun the *If the signing is rejected due to mismatched O or OU or C etc then rerun the
get-csr actions and specify the mismatched items* get-csr actions and specify the mismatched items.*
Upload signed CSR and root CA cert to vault Upload signed CSR and root CA cert to Vault
........................................... ...........................................
(Where /tmp/root-ca.pem is the root ca cert) (Where /tmp/root-ca.pem is the root ca cert)
.. code:: bash .. code-block:: none
juju run-action vault/0 upload-signed-csr \ juju run-action vault/0 upload-signed-csr \
pem="$(cat /tmp/vault-charm-int.pem | base64)" \ pem="$(cat /tmp/vault-charm-int.pem | base64)" \
@@ -123,28 +122,25 @@ Upload signed CSR and root CA cert to vault
.. note:: .. note::
The certificates provided via the 'pem' parameter must be a PEM bundle The certificates provided via the 'pem' parameter must be a PEM bundle
containing the signed certificate, any intermediate CA certs external containing the signed certificate, any intermediate CA certs external to
to Vault and the root CA cert. Without this information Vault cannot Vault and the root CA cert. Without this information Vault cannot verify
verify the trust chain and will reject the provided certificate - see the trust chain and will reject the provided certificate - see `RFC5280`_
`RFC5280`_ for more details about certificate paths and trust. for more details about certificate paths and trust.
If external intermediate CAs are in use the root-ca PEM must also If external intermediate CAs are in use the root-ca PEM must also be a PEM
be a PEM bundle including certs for all intermediate CAs and the root bundle including certs for all intermediate CAs and the root CA.
CA.
For more details about the format of certificate PEM bundles see For more details about the format of certificate PEM bundles see `RFC7468`_.
`RFC7468`_.
Vault issues certificates Vault issues certificates
~~~~~~~~~~~~~~~~~~~~~~~~~ ~~~~~~~~~~~~~~~~~~~~~~~~~
Vault will now issue certificates to all clients that have requested them. Vault will now issue certificates to all clients that have requested them. This
This process will trigger the api charms to request endpoint updates from process will trigger the api charms to request endpoint updates from keystone
keystone to reflect that they are now using https. This can be a lengthy to reflect that they are now using https. This can be a lengthy process, so
process, so monitor keystone units and wait for them to become idle. monitor keystone units and wait for them to become idle.
.. code:: bash
.. code-block:: none
watch -d juju status keystone watch -d juju status keystone
@@ -153,7 +149,7 @@ Test
Where /tmp/root-ca.pem is the root CA cert: Where /tmp/root-ca.pem is the root CA cert:
.. code:: bash .. code-block:: none
source novarc # make sure you have https in OS_AUTH_URL source novarc # make sure you have https in OS_AUTH_URL
@@ -176,7 +172,7 @@ The vault charm has an *reissue-certificates* action. Running the action
will cause vault to issue new certificates for all charm clients. The action will cause vault to issue new certificates for all charm clients. The action
must be run on the lead unit. must be run on the lead unit.
.. code:: bash .. code-block:: none
juju run-action vault/0 reissue-certificates juju run-action vault/0 reissue-certificates

6
deploy-guide/source/app-ha.rst
View File

@@ -728,8 +728,8 @@ are working nova-compute and vault applications.
Finally, you will need to provide an SSL certificate. This can be done by Finally, you will need to provide an SSL certificate. This can be done by
having Vault use a self-signed certificate or by using a certificate chain. having Vault use a self-signed certificate or by using a certificate chain.
We'll do the former here for simplicity but see `Managing TLS certificates with We'll do the former here for simplicity but see `Managing TLS certificates`_
Vault`_ for how to use a chain. for how to use a chain.
.. code-block:: none .. code-block:: none
@@ -816,7 +816,7 @@ Charms`_ project group.
.. _Clustered Database Service Model: http://docs.openvswitch.org/en/latest/ref/ovsdb.7/#clustered-database-service-model .. _Clustered Database Service Model: http://docs.openvswitch.org/en/latest/ref/ovsdb.7/#clustered-database-service-model
.. _Raft algorithm: https://raft.github.io/ .. _Raft algorithm: https://raft.github.io/
.. _Ceph bucket type: https://docs.ceph.com/docs/master/rados/operations/crush-map/#types-and-buckets .. _Ceph bucket type: https://docs.ceph.com/docs/master/rados/operations/crush-map/#types-and-buckets
.. _Managing TLS certificates with Vault: app-certificate-management.html .. _Managing TLS certificates: app-certificate-management.html
.. BUGS .. BUGS
.. _LP #1234561: https://bugs.launchpad.net/charm-ceph-osd/+bug/1234561 .. _LP #1234561: https://bugs.launchpad.net/charm-ceph-osd/+bug/1234561

6
deploy-guide/source/app-hardware-offload.rst
View File

@@ -1,6 +1,6 @@
=========================== ===================
Network hardware offloading Hardware offloading
=========================== ===================
Overview Overview
-------- --------

124
deploy-guide/source/app-octavia.rst
View File

@@ -1,42 +1,38 @@
============= ==============
Octavia LBaaS Load balancing
============= ==============
Overview Overview
-------- --------
As of the 18.11 charm release, with OpenStack Rocky and later, OpenStack OpenStack Octavia can be deployed to provide Load balancing services as part of
Octavia can be deployed to provide Load-balancing services as part of an an OpenStack cloud. This service supersedes the LBaaS v2 services provided
OpenStack Cloud. This service supersedes the LBaaS v2 services provided directly through Neutron in earlier releases; when Octavia is deployed a proxy
directly through Neutron in earlier releases; when Octavia is deployed service is configured to proxy LBaaS v2 API calls directly to Octavia.
a proxy service is configured to proxy LBaaS v2 API calls directly to
Octavia.
Octavia uses cloud resources to provision instances to provide LBaaS .. note::
services unlike the LBaaS v2 support in the OpenStack Charms which
placed haproxy instances on neutron-gateway units. Octavia is supported by Charmed OpenStack starting with OpenStack Rocky.
Octavia uses cloud resources to provision instances to provide LBaaS services
unlike the LBaaS v2 support in the OpenStack Charms which placed haproxy
instances on neutron-gateway units.
.. warning:: .. warning::
Octavia is only supported by the OpenStack Charms for OpenStack There is no automatic migration path for Neutron LBaaS haproxy-on-host
Rocky or later. configurations (as deployed under the existing support) to Octavia Amphora
configurations. New load balancers must be created in Octavia before the
.. warning:: octavia charm is related to the existing neutron-api charm. Floating IPs
can then be moved prior to deletion of existing LBaaS based balancers.
There is no automatic migration path for Neutron LBaaS
haproxy-on-host configurations (as deployed under the existing
support) to Octavia Amphora configurations. New load balancers
must be created in Octavia before the octavia charm is related
to the existing neutron-api charm. Floating IP's can then be
moved prior to deletion of existing LBaaS based balancers.
Deployment Deployment
---------- ----------
.. warning:: .. note::
Throughout this guide make sure ``openstack-origin`` matches the value you Throughout the deployment, ensure that the value for ``openstack-origin``
used when `deploying OpenStack`_. matches the currently deployed OpenStack release.
Octavia uses OpenStack Barbican to store certificates for TLS termination on Octavia uses OpenStack Barbican to store certificates for TLS termination on
load balancers. Barbican, in turn, uses Vault to securely store that data. load balancers. Barbican, in turn, uses Vault to securely store that data.
@@ -44,8 +40,8 @@ load balancers. Barbican, in turn, uses Vault to securely store that data.
.. note:: .. note::
For Vault deployment instructions see the `vault charm`_. For certificate For Vault deployment instructions see the `vault charm`_. For certificate
management information read the `Managing TLS certificates with Vault`_ management information read the `Managing TLS certificates`_ section of this
section of this guide. guide.
To deploy Barbican: To deploy Barbican:
@@ -59,7 +55,8 @@ To deploy Barbican:
juju add-relation barbican barbican-vault juju add-relation barbican barbican-vault
juju add-relation barbican-vault vault juju add-relation barbican-vault vault
Octavia can then be deployed: Octavia can then be deployed. Use the appropriate section depending on your
cloud's networking framework:
Neutron ML2+OVS Neutron ML2+OVS
~~~~~~~~~~~~~~~ ~~~~~~~~~~~~~~~
@@ -91,28 +88,25 @@ Neutron ML2+OVN
juju deploy octavia-dashboard juju deploy octavia-dashboard
juju add-relation octavia-dashboard openstack-dashboard juju add-relation octavia-dashboard openstack-dashboard
.. note:: .. note::
Octavia uses a Neutron network for communication between Octavia uses a Neutron network for communication between Octavia control
Octavia control plane services and Octavia Amphorae; units will plane services and Octavia Amphorae; units will deploy into a 'blocked'
deploy into a 'blocked' state until the configuration steps state until the configuration steps are executed.
are executed.
Configuration Configuration
------------- -------------
Generate Certificates Generate certificates
~~~~~~~~~~~~~~~~~~~~~ ~~~~~~~~~~~~~~~~~~~~~
Octavia uses client certificates for authentication and security of Octavia uses client certificates for authentication and security of
communication between Amphorae (load balancers) and the Octavia communication between Amphorae (load balancers) and the Octavia control plane;
control plane; for the initial version of the Octavia charm, these for the initial version of the Octavia charm, these must be generated by the
must be generated by the operator and provided to the Octavia charm operator and provided to the Octavia charm as configuration.
as configuration.
The script below generates example certificates and keys with a 365 The script below generates example certificates and keys with a 365 day expiry
day expiry period: period:
.. code-block:: none .. code-block:: none
@@ -143,8 +137,7 @@ day expiry period:
-in controller.csr -days 365 -out controller_cert.pem -in controller.csr -days 365 -out controller_cert.pem
cat controller_cert.pem controller_key.pem > controller_cert_bundle.pem cat controller_cert.pem controller_key.pem > controller_cert_bundle.pem
The generated certificates and keys must then be provided to the octavia charm:
The generated certs and keys must then be provided to the octavia charm:
.. code-block:: none .. code-block:: none
@@ -160,7 +153,7 @@ The generated certs and keys must then be provided to the octavia charm:
Future versions of the charm may automatically generate the internal Future versions of the charm may automatically generate the internal
Certification Authority required to operate Octavia. Certification Authority required to operate Octavia.
Resource Configuration Resource configuration
~~~~~~~~~~~~~~~~~~~~~~ ~~~~~~~~~~~~~~~~~~~~~~
The charm will automatically create and maintain the resources required for The charm will automatically create and maintain the resources required for
@@ -184,9 +177,9 @@ full custom configuration of the management network for Octavia. If you want
to manage these resources yourself you must set the `create-mgmt-network` to manage these resources yourself you must set the `create-mgmt-network`
configuration option to false. configuration option to false.
Network resources for use by Octavia must be tagged using Neutron resource Network resources for use by Octavia must be tagged using Neutron resource tags
tags (typically by passing a '--tag' CLI parameter when creating resources - (typically by passing a '--tag' CLI parameter when creating resources - see the
see the OpenStack CLI for more details) using the following schema: OpenStack CLI for more details) using the following schema:
=========================== ====================== ========================================================= =========================== ====================== =========================================================
Resource Type Tag Description Resource Type Tag Description
@@ -199,8 +192,8 @@ Controller Security Group charm-octavia-health Security group for Controller
=========================== ====================== ========================================================= =========================== ====================== =========================================================
Execution of the `configure-resources` action will detect the pre-configured Execution of the `configure-resources` action will detect the pre-configured
network resources in Neutron using tags and configure the Octavia service network resources in Neutron using tags and configure the Octavia service as
as appropriate. appropriate.
The UUID of the Nova flavor to use for Amphorae can be set using the The UUID of the Nova flavor to use for Amphorae can be set using the
`custom-amp-flavor-id` configuration option. `custom-amp-flavor-id` configuration option.
@@ -208,8 +201,9 @@ The UUID of the Nova flavor to use for Amphorae can be set using the
Amphora image Amphora image
~~~~~~~~~~~~~ ~~~~~~~~~~~~~
Octavia uses Amphorae (cloud instances running HAProxy) to provide LBaaS services; Octavia uses Amphorae (cloud instances running HAProxy) to provide LBaaS
an appropriate image must be uploaded to Glance with the tag `octavia-amphora`. services; an appropriate image must be uploaded to Glance with the tag
`octavia-amphora`.
You can use the ``octavia-diskimage-retrofit`` tool to transform a stock Ubuntu You can use the ``octavia-diskimage-retrofit`` tool to transform a stock Ubuntu
cloud image into a Octavia HAProxy Amphora image. cloud image into a Octavia HAProxy Amphora image.
@@ -236,7 +230,7 @@ After the deployment has settled and ``glance-simplestreams-sync`` has
completed its initial image sync, you may ask a ``octavia-diskimage-retrofit`` completed its initial image sync, you may ask a ``octavia-diskimage-retrofit``
unit to initiate the Amphora image retrofitting process. unit to initiate the Amphora image retrofitting process.
This is accomplished through running an action on one of the units. This is accomplished by running an action on one of the units.
.. code-block:: none .. code-block:: none
@@ -246,9 +240,8 @@ Octavia will use this image for all Amphora instances.
.. warning:: .. warning::
It's important to keep the Amphora image up-to-date to ensure that It's important to keep the Amphora image up-to-date to ensure that LBaaS
LBaaS services remain secure; this process is not covered in this services remain secure; this process is not covered in this document.
document.
See the Octavia `operators maintenance`_ guide for more details. See the Octavia `operators maintenance`_ guide for more details.
@@ -275,23 +268,24 @@ To deploy a basic HTTP load balancer using a floating IP for access:
The example above assumes: The example above assumes:
- The user and project executing the example has a subnet configured * The user and project executing the example has a subnet configured with the
with the name `private_subnet` with the CIDR 192.168.21.0/24 name 'private_subnet' with the CIDR 192.168.21.0/24
- An external network definition for floating IP's has been configured
by the cloud operator with the name `ext_net`
- Two instances running HTTP services attached to the `private_subnet`
on IP addresses 192.168.21.{100,101} exposing a heat check on `/healthcheck`
The example is also most applicable in cloud deployments which use overlay * An external network definition for floating IPs has been configured by the
networking for project networks and floating IP's for network ingress to project cloud operator with the name 'ext_net'
* Two instances running HTTP services attached to 'private_subnet' on IP
addresses 192.168.21.{100,101} exposing a heat check on '/healthcheck'
The example is also most applicable in cloud deployments that use overlay
networking for project networks and floating IPs for network ingress to project
networks. networks.
For more information on creating and configuring load balancing services in For more information on creating and configuring load balancing services in
Octavia please refer to the `Octavia cookbook`_. Octavia please refer to the `Octavia cookbook`_.
.. LINKS .. LINKS
.. _deploying OpenStack: install-openstack.html .. _Managing TLS certificates: app-certificate-management.html
.. _Managing TLS certificates with Vault: app-certificate-management.html
.. _Octavia Policies: https://docs.openstack.org/octavia/latest/configuration/policy.html .. _Octavia Policies: https://docs.openstack.org/octavia/latest/configuration/policy.html
.. _Octavia cookbook: https://docs.openstack.org/octavia/latest/user/guides/basic-cookbook.html .. _Octavia cookbook: https://docs.openstack.org/octavia/latest/user/guides/basic-cookbook.html
.. _operators maintenance: https://docs.openstack.org/octavia/latest/admin/guides/operator-maintenance.html#rotating-the-amphora-images .. _operators maintenance: https://docs.openstack.org/octavia/latest/admin/guides/operator-maintenance.html#rotating-the-amphora-images

34
deploy-guide/source/app-ovn.rst
View File

@@ -5,10 +5,8 @@ Open Virtual Network (OVN)
Overview Overview
-------- --------
As of the 19.10 OpenStack Charms release, with OpenStack Train or later, Open Virtual Network (OVN) can be deployed to provide networking services as
support for integration with Open Virtual Network (OVN) is available. As of part of an OpenStack cloud.
the 20.05 OpenStack Charms release OVN is the preferred default for our
`OpenStack Base bundle`_ reference implementation.
.. note:: .. note::
@@ -25,6 +23,12 @@ OVN charms:
* ovn-dedicated-chassis * ovn-dedicated-chassis
.. note::
OVN is supported by Charmed OpenStack starting with OpenStack Train. OVN is
the default configuration in the `OpenStack Base bundle`_ reference
implementation.
Deployment Deployment
---------- ----------
@@ -36,8 +40,8 @@ Certificates must be managed by Vault.
.. note:: .. note::
For Vault deployment instructions see the `vault charm`_. For certificate For Vault deployment instructions see the `vault charm`_. For certificate
management information read the `Managing TLS certificates with Vault`_ management information read the `Managing TLS certificates`_ section of this
section of this guide. guide.
To deploy OVN: To deploy OVN:
@@ -104,8 +108,7 @@ for use with hardware offloading and make them available to OpenStack.
To use the feature you need to use supported network interface card (NIC) To use the feature you need to use supported network interface card (NIC)
hardware. We have done feature validation using the Mellanox ConnectX-5 NICs. hardware. We have done feature validation using the Mellanox ConnectX-5 NICs.
Please refer to `Network hardware offloading`_ for more background on the Please refer to `Hardware offloading`_ for more background on the feature.
feature.
Hardware offload support makes use of SR-IOV as an underlying mechanism to Hardware offload support makes use of SR-IOV as an underlying mechanism to
accelerate the data path between a virtual machine instance and the NIC accelerate the data path between a virtual machine instance and the NIC
@@ -121,9 +124,8 @@ with appropriate driver and firmware support.
Prerequisites Prerequisites
^^^^^^^^^^^^^ ^^^^^^^^^^^^^
Please refer to the `SR-IOV for networking support`_ section and the `Network Please refer to the `SR-IOV for networking support`_ section and the `Hardware
hardware offloading`_ page for information on hardware and kernel offloading`_ page for information on hardware and kernel configuration.
configuration.
Charm configuration Charm configuration
^^^^^^^^^^^^^^^^^^^ ^^^^^^^^^^^^^^^^^^^
@@ -814,9 +816,9 @@ of the actual migration.
topology. topology.
5. Unseal Vault (see the `vault charm`_), set up TLS certificates (see 5. Unseal Vault (see the `vault charm`_), set up TLS certificates (see
`Managing TLS certificates with Vault`_), and validate that the services on `Managing TLS certificates`_), and validate that the services on ovn-central
ovn-central units are running as expected. Please refer to the `Usage`_ units are running as expected. Please refer to the `Usage`_ section for more
section for more information. information.
Perform migration Perform migration
~~~~~~~~~~~~~~~~~ ~~~~~~~~~~~~~~~~~
@@ -1002,7 +1004,7 @@ Perform migration
.. LINKS .. LINKS
.. _vault charm: https://jaas.ai/vault/ .. _vault charm: https://jaas.ai/vault/
.. _Managing TLS certificates with Vault: app-certificate-management.html .. _Managing TLS certificates: app-certificate-management.html
.. _Toward Convergence of ML2+OVS+DVR and OVN: http://specs.openstack.org/openstack/neutron-specs/specs/ussuri/ml2ovs-ovn-convergence.html .. _Toward Convergence of ML2+OVS+DVR and OVN: http://specs.openstack.org/openstack/neutron-specs/specs/ussuri/ml2ovs-ovn-convergence.html
.. _ovn-dedicated-chassis charm: https://jaas.ai/u/openstack-charmers/ovn-dedicated-chassis/ .. _ovn-dedicated-chassis charm: https://jaas.ai/u/openstack-charmers/ovn-dedicated-chassis/
.. _networking-ovn plugin: https://docs.openstack.org/networking-ovn/latest/ .. _networking-ovn plugin: https://docs.openstack.org/networking-ovn/latest/
@@ -1017,7 +1019,7 @@ Perform migration
.. _DPDK supported hardware page: http://core.dpdk.org/supported/ .. _DPDK supported hardware page: http://core.dpdk.org/supported/
.. _MAAS: https://maas.io/ .. _MAAS: https://maas.io/
.. _Customizing instance huge pages allocations: https://docs.openstack.org/nova/latest/admin/huge-pages.html#customizing-instance-huge-pages-allocations .. _Customizing instance huge pages allocations: https://docs.openstack.org/nova/latest/admin/huge-pages.html#customizing-instance-huge-pages-allocations
.. _Network hardware offloading: app-hardware-offload.html .. _Hardware offloading: app-hardware-offload.html
.. _SR-IOV for networking support: app-ovn.html#sr-iov-for-networking-support .. _SR-IOV for networking support: app-ovn.html#sr-iov-for-networking-support
.. _traffic control monitor: http://manpages.ubuntu.com/manpages/focal/man8/tc.8.html#monitor .. _traffic control monitor: http://manpages.ubuntu.com/manpages/focal/man8/tc.8.html#monitor
.. _data path control tools: http://manpages.ubuntu.com/manpages/focal/man8/ovs-dpctl.8.html .. _data path control tools: http://manpages.ubuntu.com/manpages/focal/man8/ovs-dpctl.8.html

15
deploy-guide/source/upgrade-issues.rst
View File

@@ -2,7 +2,8 @@
Known upgrade issues Known upgrade issues
==================== ====================
This section documents known software upgrade issues. This section documents known issues that may apply to either of the three
upgrade types (charms, OpenStack, series).
DNS HA with the focal series DNS HA with the focal series
---------------------------- ----------------------------
@@ -37,16 +38,16 @@ See bug `LP #1809190`_.
cinder/ceph topology change: upgrading from Newton to Ocata cinder/ceph topology change: upgrading from Newton to Ocata
----------------------------------------------------------- -----------------------------------------------------------
If ``cinder`` is directly related to ``ceph-mon`` rather than via If cinder is directly related to ceph-mon rather than via cinder-ceph then
``cinder-ceph`` then upgrading from Newton to Ocata will result in the loss of upgrading from Newton to Ocata will result in the loss of some block storage
some block storage functionality, specifically live migration and snapshotting. functionality, specifically live migration and snapshotting. To remedy this
To remedy this situation the deployment should migrate to using the cinder-ceph situation the deployment should migrate to using the cinder-ceph charm. This
charm. This can be done after the upgrade to Ocata. can be done after the upgrade to Ocata.
.. warning:: .. warning::
Do not attempt to migrate a deployment with existing volumes to use the Do not attempt to migrate a deployment with existing volumes to use the
``cinder-ceph`` charm prior to Ocata. cinder-ceph charm prior to Ocata.
The intervention is detailed in the below three steps. The intervention is detailed in the below three steps.

6
deploy-guide/source/upgrade-special.rst
View File

@@ -1,6 +1,6 @@
========================== ================================
Special upgrade procedures Special charm upgrade procedures
========================== ================================
The OpenStack charms are designed to accommodate every supported series and The OpenStack charms are designed to accommodate every supported series and
OpenStack release wherever possible. However, upgrades may occasionally OpenStack release wherever possible. However, upgrades may occasionally