From c74ce0fbdf81996331d7bddd259e15492ce7ee1d Mon Sep 17 00:00:00 2001 From: Peter Matulis Date: Tue, 5 Nov 2019 16:31:19 -0500 Subject: [PATCH] No mixing of charm releases nor series versions I realise now that 'Charm upgrades' should be on its own page as they can be done independently of an OpenStack upgrade. A future PR may address this. Closes-Bug: #1811867 Change-Id: I6c9520ba2b81a358a66bdb0be92410c90dfaccf2 --- deploy-guide/source/app-ceph-migration.rst | 14 ++++++++++++++ deploy-guide/source/app-series-upgrade.rst | 16 ++++++++++++++-- deploy-guide/source/install-openstack.rst | 22 +++++++++++++++++++++- 3 files changed, 49 insertions(+), 3 deletions(-) diff --git a/deploy-guide/source/app-ceph-migration.rst b/deploy-guide/source/app-ceph-migration.rst index 633c620..2119174 100644 --- a/deploy-guide/source/app-ceph-migration.rst +++ b/deploy-guide/source/app-ceph-migration.rst @@ -11,6 +11,14 @@ should migrate existing services to using ceph-mon and ceph-osd. 0, 1 and 2 with the ceph-osd charm deployed to other machines within the model. +Upgrade charms +~~~~~~~~~~~~~~ + +The entire suite of charms used to manage the cloud should be upgraded to the +latest stable charm revision before any major change is made to the cloud such +as the current migration to these new charms. See `Charm upgrades`_ for +guidance. + Deploy ceph-mon ~~~~~~~~~~~~~~~ @@ -97,3 +105,9 @@ As each unit of the ceph application is destroyed, its stop hook will remove the MON process from the Ceph cluster monmap and disable Ceph MON and MGR processes running on the machine; any Ceph OSD processes remain untouched and are now owned by the ceph-osd units deployed alongside ceph. + +.. raw:: html + + + +.. _Charm upgrades: app-upgrade-openstack#charm-upgrades diff --git a/deploy-guide/source/app-series-upgrade.rst b/deploy-guide/source/app-series-upgrade.rst index 08642e2..b9852db 100644 --- a/deploy-guide/source/app-series-upgrade.rst +++ b/deploy-guide/source/app-series-upgrade.rst @@ -7,6 +7,11 @@ Introduction Juju and OpenStack charms provide the primitives to prepare for and respond to an upgrade from one Ubuntu LTS series to another. +.. note:: + + The recommended best practice is that the Juju machines that comprise the + cloud should eventually all be running the same series (e.g. 'xenial' or + 'bionic', but not a mix of the two). Warnings ++++++++ @@ -97,11 +102,12 @@ This document makes a number of assumptions about the architecture and preparation of the cloud undergoing series upgrade. Please review these and compare to the running cloud before performing the series upgrade. - Preparations ~~~~~~~~~~~~ -Charms are upgraded to the latest release. +The entire suite of charms used to manage the cloud should be upgraded to the +latest stable charm revision before any major change is made to the cloud such +as the current machine series upgrades. See `Charm upgrades`_ for guidance. OpenStack is upgraded to the highest version the current LTS supports. Mitaka for Trusty and Queens for Xenial. @@ -479,3 +485,9 @@ Juju set-series to the new series for all future units of an application. .. code:: bash juju set-series keystone xenial + +.. raw:: html + + + +.. _Charm upgrades: app-upgrade-openstack#charm-upgrades diff --git a/deploy-guide/source/install-openstack.rst b/deploy-guide/source/install-openstack.rst index 316b731..e1c2757 100644 --- a/deploy-guide/source/install-openstack.rst +++ b/deploy-guide/source/install-openstack.rst @@ -27,6 +27,21 @@ Alternatively, jump to :doc:`Deploying OpenStack from a bundle ` to learn about deploying as a bundle. +.. important:: + + Irrespective of install method, once the cloud is deployed, the following + management practices related to charm versions and machine series are + recommended: + + #. The entire suite of charms used to manage the cloud should be upgraded to + the latest stable charm revision before any major change is made to the + cloud (e.g. migrating to new charms, upgrading cloud services, upgrading + machine series). See `Charm upgrades`_ for details. + + #. The Juju machines that comprise the cloud should all be running the same + series (e.g. 'xenial' or 'bionic', but not a mix of the two). See `Series + upgrade`_ for details. + Deploy the Juju controller -------------------------- @@ -102,7 +117,8 @@ and deploy Ceph-OSD to each of the four nodes: If a message from a ceph-osd unit like "Non-pristine devices detected" appears in the output of :command:`juju status` you will need to use actions - ``zap-disk`` and ``add-disk`` that come with the 'ceph-osd' charm. + ``zap-disk`` and ``add-disk`` that come with the 'ceph-osd' charm if you do + in fact want to purge the disk of all data and signatures for use by Ceph. In the background, Juju will ask MAAS to commission the nodes, powering them on and installing Ubuntu. Juju then takes over and installs the necessary packages @@ -546,6 +562,10 @@ OpenStack ` for use within a production environment. +.. _OpenStack Charms: https://docs.openstack.org/charm-guide/latest/openstack-charms.html +.. _Charm upgrades: app-upgrade-openstack#charm-upgrades +.. _Series upgrade: app-series-upgrade + .. raw:: html