Upgrade the OpenStack environment 6.1 to 7.0
Add chapter to Operations document with description of procedure that upgrades Mirantis OpenStack environment 6.1 to 7.0 for limited set of Reference Architecture options. Change-Id: I9a0df955aa0c2feafcb6e9810144baa5a22491a4 Implements: blueprint upgrade-major-openstack-environment
This commit is contained in:
parent
1476b352c0
commit
5aee328958
Binary file not shown.
After Width: | Height: | Size: 389 KiB |
Binary file not shown.
After Width: | Height: | Size: 1.2 MiB |
|
@ -34,6 +34,7 @@
|
|||
.. include:: /pages/operations/8900-testing-details.rst
|
||||
.. include:: /pages/operations/corosync2.rst
|
||||
.. include:: /pages/operations/9000-troubleshoot.rst
|
||||
.. include:: /pages/operations/9600-upgrade.rst
|
||||
.. include:: /pages/operations/ha-testing-scenarios-ops.rst
|
||||
.. include:: /pages/operations/db-backup-ops.rst
|
||||
.. include:: /pages/operations/isoUSB-ops.rst
|
||||
|
|
|
@ -0,0 +1,15 @@
|
|||
.. index:: OpenStack-Upgrade Guide
|
||||
|
||||
.. _OS-Upgrade-Guide:
|
||||
|
||||
.. contents:: :local:
|
||||
:depth: 2
|
||||
|
||||
Upgrade Environment (EXPERIMENTAL)
|
||||
==================================
|
||||
|
||||
.. include:: /pages/operations/upgrade/1000-overview.rst
|
||||
.. include:: /pages/operations/upgrade/1010-quick-start.rst
|
||||
.. include:: /pages/operations/upgrade/2000-solution-overview.rst
|
||||
.. include:: /pages/operations/upgrade/3000-upgrade-script.rst
|
||||
.. include:: /pages/operations/upgrade/4000-finalize-upgrade.rst
|
|
@ -0,0 +1,138 @@
|
|||
.. index:: Upgrade Overview
|
||||
|
||||
.. _Upg_Over:
|
||||
|
||||
Overview
|
||||
--------
|
||||
|
||||
Upgrading Mirantis OpenStack from version 6.1 to version 7.0 involves
|
||||
building new environment, installing an HA Controller node in that environment,
|
||||
alongside with the old Controller nodes, switching all compute nodes to the new
|
||||
controller nodes, and then upgrading the Compute nodes.
|
||||
|
||||
You do not need any new hardware for the upgrade.
|
||||
|
||||
.. warning::
|
||||
|
||||
During the upgrade it virtual machines and other resources might experience
|
||||
temporary network disconnects. Schedule the upgrade during maintenance
|
||||
window.
|
||||
|
||||
Upgrade Scenario
|
||||
++++++++++++++++
|
||||
|
||||
The proposed solution includes the following general steps described
|
||||
below in more details:
|
||||
|
||||
* OpenStack environment of version 7.0 is created using Fuel API with
|
||||
the settings and network configurations matching the configuration of
|
||||
the original 6.1 environment.
|
||||
* One of the :ref:`Cloud Infrastructure Controllers <cic-term>` (CICs)
|
||||
in the original 6.1 environment is deleted and moved to the
|
||||
6.1 environment. It is then installed in that environment as
|
||||
a primary controller side-by-side with the original 6.1 environment.
|
||||
* All OpenStack platform services are put into :ref:`Maintenance Mode
|
||||
<db-backup-ops>` for the whole duration of the upgrade procedure to
|
||||
prevent user data loss and/or corruption.
|
||||
* Copy the state databases of all the upgradeable OpenStack components
|
||||
to the new Controller and upgrade these wuth the standard
|
||||
‘database migration’ feature of OpenStack.
|
||||
* Reconfigure the Ceph cluster in such a way that the Monitors on the
|
||||
new 7.0 CICs replace the Monitors of the 6.1 environment, retaining
|
||||
the original IP addresses and configuration parameters.
|
||||
* The 7.0 CIC is connected to the Management and External networks,
|
||||
while the original 6.1 ones are disconnected. The 7.0 CIC takes
|
||||
over Virtual IPs in the Management and Public :ref:`networks <logical-networks-arch>`.
|
||||
* Control plane services on the Compute nodes in the 6.1 environment
|
||||
are upgraded to 7.0 without affecting the virtual server instances
|
||||
and workloads. After the upgrade, the Compute service reconnects to
|
||||
7.0 CICs.
|
||||
* Compute nodes from the 6.1 environment work with the CICs from the
|
||||
7.0 environment, forming a temporary hybrid OpenStack environment
|
||||
that is only used to upgrade the Compute nodes one by one by
|
||||
re-assigning them to the 7.0 environment and re-installing with
|
||||
the new version.
|
||||
* Ceph OSD nodes from the 6.1 environment transparently switch to
|
||||
the new Monitors without the actual data moving in the Ceph cluster.
|
||||
* User data stored on OSD nodes must be preserved through
|
||||
re-installation of the nodes into a new release of the operating
|
||||
system and OpenStack services, and OSD nodes must connect to the
|
||||
Monitors without changing their original IDs and data set.
|
||||
|
||||
Every step requires certain actions. All of these actions are scripted
|
||||
as subcommands to the upgrade script called 'octane'.
|
||||
|
||||
Prerequisites and dependencies
|
||||
++++++++++++++++++++++++++++++
|
||||
|
||||
The procedure of upgrading Mirantis OpenStack from 6.1 to 7.0 version
|
||||
has certain prerequisites and dependencies. You need to verify if your
|
||||
installation of Mirantis OpenStack meets these requirements.
|
||||
|
||||
Fuel installer
|
||||
______________
|
||||
|
||||
Mirantis OpenStack 6.1 environment must be deployed and managed by
|
||||
Fuel installer to be upgradeable. If you installed your environment
|
||||
without leveraging Fuel, or removed the :ref:`Fuel Master node <fuel-master-node-term>`
|
||||
from the installation after a successful deployment, you will not be
|
||||
able to upgrade your environments using these instructions.
|
||||
|
||||
The upgrade scenario deviates from the standard sequence used in Fuel
|
||||
installer to deploy Mirantis OpenStack environment. These modifications
|
||||
to the behavior of the installer are implemented as modifications to the
|
||||
:ref:`deployment tasks <0010-tasks-schema>` and extensions to certain
|
||||
components of Fuel. Patches are applied to the Fuel Master node as part
|
||||
of 'preparation' phase of the Upgrade scenario. See the sections below
|
||||
for the detailed description of which components are modified and why.
|
||||
|
||||
.. _architecture-constraints:
|
||||
|
||||
Architecture constraints
|
||||
________________________
|
||||
|
||||
Make sure that your Mirantis OpenStack 6.1 environment meets
|
||||
the following architecture constraints. Otherwise, these instructions
|
||||
will not work for you:
|
||||
|
||||
+----------------------------------------------------+------------------+
|
||||
| Constraint | Check if comply |
|
||||
+====================================================+==================+
|
||||
| High Availability architecture | |
|
||||
+----------------------------------------------------+------------------+
|
||||
| Ubuntu 14.04 as an operating system | |
|
||||
+----------------------------------------------------+------------------+
|
||||
| Neutron networking manager with OVS+VLAN plugin | |
|
||||
+----------------------------------------------------+------------------+
|
||||
| Cinder virtual block storage volumes | |
|
||||
+----------------------------------------------------+------------------+
|
||||
| Ceph shared storage for volumes and ephemeral data | |
|
||||
+----------------------------------------------------+------------------+
|
||||
| Ceph shared storage for images and objeсt store | |
|
||||
+----------------------------------------------------+------------------+
|
||||
|
||||
Fuel upgrade to 7.0
|
||||
___________________
|
||||
|
||||
In this guide we assume that the user upgrades Fuel installer from
|
||||
version 6.1 to 7.0. The upgrade of Fuel installer is a standard
|
||||
feature of the system. Upgraded Fuel retains the ability to manage
|
||||
6.1 environments, which is leveraged by the environment upgrade solution.
|
||||
|
||||
Additional hardware
|
||||
___________________
|
||||
|
||||
The upgrade strategy requires installing 7.0 environment that will
|
||||
result in an OpenStack cluster along with the original environment.
|
||||
One of the Controller nodes from the original 6.1 environment will
|
||||
be deleted, added to the new 7.0 environment, and reinstalled. This
|
||||
allows performing an upgrade with no additional hardware.
|
||||
|
||||
.. note::
|
||||
|
||||
The trade-off for using one of the existing controllers as a
|
||||
primary upgraded controller is that the 7.0 environment will
|
||||
not be highly available for some time during the maintenance
|
||||
window dedicated to the upgrade. Once the remaining controllers
|
||||
are moved from the 6.1 environment and reinstalled into the 7.0
|
||||
environment, its High Availability is restored.
|
|
@ -0,0 +1,147 @@
|
|||
.. index:: Upgrade Environment Quick Start
|
||||
|
||||
.. _Upg_QuickStart:
|
||||
|
||||
Upgrade Environment Quick Start
|
||||
-------------------------------
|
||||
|
||||
.. CAUTION::
|
||||
|
||||
Only use this section as a reference. Read the detailed sections
|
||||
below to understand the upgrade scenario before running any of
|
||||
the listed commands.
|
||||
|
||||
This section lists commands required to upgrade a 6.1 environment to
|
||||
version 7.0 with brief comments. For the detailed description of what
|
||||
each command does and why, see the following sections:
|
||||
|
||||
* :ref:`Detailed upgrade procedure<upg_sol>`
|
||||
* :ref:`Detailed description of commands<upg_script>`
|
||||
|
||||
.. CAUTION::
|
||||
|
||||
Do not run the following commands unless you understand exactly
|
||||
what you are doing. It can completely destroy your OpenStack
|
||||
environment. Please, read the detailed sections below carefully
|
||||
before you proceed with these commands.
|
||||
|
||||
*1. Install the Upgrade Script*
|
||||
|
||||
Run the following command on the Fuel Master node to download and
|
||||
install the Upgrade Script in the system:
|
||||
|
||||
::
|
||||
|
||||
yum install -y fuel-octane
|
||||
octane prepare
|
||||
|
||||
*2. Pick environment to upgrade*
|
||||
|
||||
Run the following command and pick an environment to upgrade from the
|
||||
list:
|
||||
|
||||
::
|
||||
|
||||
fuel2 env list
|
||||
|
||||
Note the ID of the environment and store it in a variable:
|
||||
|
||||
::
|
||||
|
||||
export ORIG_ID=<ID>
|
||||
|
||||
*3. Create an Upgrade Seed environment*
|
||||
|
||||
Run the following command to create a new environment of version 7.0
|
||||
and store its ID to a variable:
|
||||
|
||||
::
|
||||
|
||||
SEED_ID=$(./octane upgrade-env $ORIG_ID)
|
||||
|
||||
*4. Upgrade the first Controller*
|
||||
|
||||
Pick one of the Controllers in your environment by ID and remember
|
||||
that ID:
|
||||
|
||||
::
|
||||
|
||||
fuel node list --env ${ORIG_ID} | awk -F\| '$7~/controller/{print($0)}'
|
||||
|
||||
Use the ID of the Controller to upgrade it with the following command:
|
||||
|
||||
::
|
||||
|
||||
octane upgrade-node --isolated $SEED_ID <ID>
|
||||
|
||||
*5. Upgrade State Database*
|
||||
|
||||
After the first Controller in the 7.0 environment is deployed and
|
||||
ready, run the following command to upgrade the state databases
|
||||
the of OpenStack services:
|
||||
|
||||
::
|
||||
|
||||
octane upgrade-db $ORIG_ID $SEED_ID
|
||||
|
||||
*6. Upgrade Ceph cluster*
|
||||
|
||||
Run the following command to upgrade the Monitor node on the new
|
||||
Controller with the state and configuration of the original Ceph
|
||||
cluster:
|
||||
|
||||
::
|
||||
|
||||
octane upgrade-ceph $ORIG_ID $SEED_ID
|
||||
|
||||
*7. Switch control plane to 7.0*
|
||||
|
||||
Run the following command to switch the OpenStack environment to the
|
||||
7.0 control plane:
|
||||
|
||||
::
|
||||
|
||||
octane upgrade-controlplane $ORIG_ID $SEED_ID
|
||||
|
||||
*8. Upgrade all Controllers*
|
||||
|
||||
Identify the remaining Controllers in the 6.1 environment by IDs
|
||||
(ID1, ID2, etc):
|
||||
|
||||
::
|
||||
|
||||
fuel node list --env ${ORIG_ID} | awk -F\| '$7~/controller/{print($0)}'
|
||||
|
||||
Run the following command to upgrade the remaining 6.1 Controllers
|
||||
to version 7.0:
|
||||
|
||||
::
|
||||
|
||||
octane upgrade-node $SEED_ID <ID1> <ID2>
|
||||
|
||||
*9. Upgrade Compute and Ceph OSD nodes*
|
||||
|
||||
Repeat the following command for every node in the 6.1 environment
|
||||
identified by ID:
|
||||
|
||||
::
|
||||
|
||||
octane upgrade-node $SEED_ID <ID>
|
||||
|
||||
*10. Clean up the Fuel Master node*
|
||||
|
||||
When no nodes remain in the 6.1 environment, run the following
|
||||
command to restore the original state of the 7.0 Fuel Master node:
|
||||
|
||||
::
|
||||
|
||||
octane cleanup-fuel
|
||||
|
||||
*11. Delete the original 6.1 environment*
|
||||
|
||||
After verification of the upgraded 7.0 environment, delete the
|
||||
original 6.1 environment with the following command:
|
||||
|
||||
::
|
||||
|
||||
fuel env --env $ORIG_ID --delete
|
|
@ -0,0 +1,345 @@
|
|||
.. index:: Upgrade Solution
|
||||
|
||||
.. _Upg_Sol:
|
||||
|
||||
Solution Overview
|
||||
-----------------
|
||||
|
||||
This section describes a solution that implements the upgrade strategy
|
||||
outlined in the previous section. It gives a step by step script of the
|
||||
procedure and explains every step of it. In the chapters that follow we
|
||||
will give detailed scripts with exact commands to upgrade your cluster.
|
||||
|
||||
Hardware considerations
|
||||
+++++++++++++++++++++++
|
||||
|
||||
For Mirantis OpenStack with :ref:`High Availability Reference Architecture
|
||||
<controller-arch>` using at least 3 CICs is recommended. When you
|
||||
install a 7.0 Seed environment in HA mode, you can start with only 1
|
||||
Controller. This procedure assumes that the node for this Controller is
|
||||
borrowed from the set of the Controllers in the original 6.1
|
||||
environment.
|
||||
|
||||
Preparations and prerequisites
|
||||
++++++++++++++++++++++++++++++
|
||||
|
||||
Before starting the upgrade itself, make sure that your system complies
|
||||
to the :ref:`architecture constraints <architecture-constraints>`
|
||||
listed above. You will also need to make some preparations to provide
|
||||
prerequisites for the upgrade procedure. These preparations are
|
||||
automated using the Upgrade Script named ``octane``.
|
||||
|
||||
Install the upgrade script on the Fuel Master node using ``yum``:
|
||||
|
||||
::
|
||||
|
||||
yum install fuel-octane
|
||||
|
||||
Create 7.0 Seed environment
|
||||
++++++++++++++++++++++++++++
|
||||
|
||||
Our concept of the upgrade involves installing a CIC of version 7.0
|
||||
side-by-side with the cloud being upgraded. We leverage Fuel installer
|
||||
for the task of deployment of nodes with 7.0 versions.
|
||||
|
||||
The way we create the upgraded environment is different from the way
|
||||
the ordinary OpenStack cluster is installed by Fuel 7.0. This section
|
||||
explains the specifics of the deployment of such a 'shadow' environment,
|
||||
also referred to as Upgrade Seed environment in this section.
|
||||
|
||||
Clone configuration of 6.1 environment
|
||||
________________________________________
|
||||
|
||||
The first step in the upgrade procedure is to install a new 7.0 Upgrade
|
||||
Seed environment. The settings and attributes of the Seed environment
|
||||
must match the settings of the original environment, with the changes
|
||||
corresponding to the changes in the data model of Nailgun between
|
||||
releases.
|
||||
|
||||
As part of the upgrade procedure automation, an extension to Nailgun
|
||||
API was developed. This extension implements a resource
|
||||
``/api/v1/cluster/<:id>/upgrade/clone`` which creates an Upgrade Seed
|
||||
environment based on the settings of the original one
|
||||
(identified by the ``id`` parameter).
|
||||
|
||||
A ``POST`` request to that resource must be sent to initiate the
|
||||
upgrade procedure.
|
||||
|
||||
An extension to the Fuel client was developed that allows sending
|
||||
the request from the CLI of the Fuel Master node.
|
||||
|
||||
Fuel client extension is installed in the
|
||||
:ref:`preparation phase <upg_prep>` of the upgrade procedure.
|
||||
|
||||
Install 7.0 CIC
|
||||
+++++++++++++++
|
||||
|
||||
When the Fuel Master node and Upgrade Seed environment are prepared,
|
||||
you can start upgrading your 6.1 environment. First you need to pick
|
||||
a Controller node in the original environment. Upgrade script will
|
||||
move that node into the Upgrade Seed environment and reinstall it as
|
||||
a primary controller in that environment.
|
||||
|
||||
The Fuel installer deploys the Cloud Controller in a Seed environment
|
||||
with the following changes:
|
||||
|
||||
* 7.0 Controller will be isolated from the Management and Public
|
||||
networks on the data link layer (L2) to avoid conflicts with the
|
||||
Virtual IPs in the original 6.1 Controllers.
|
||||
|
||||
The nature of network isolation defines many aspects of the deployment
|
||||
process. To understand how it could be implemented, we need to analyze
|
||||
the configuration of the internal networking of Cloud Infrastructure
|
||||
Controller.
|
||||
|
||||
Fuel creates virtual bridges that connect the host to networks with
|
||||
different roles. Physical interfaces (e.g. ``eth1``) are added to those
|
||||
bridges creating L2 connections to the corresponding networks.
|
||||
|
||||
On the other hand, L3 IP address is assigned to virtual bridge
|
||||
to the network of a given type. A virtual bridge to connect to
|
||||
Management network is called ``br-mgmt``, to Public network -
|
||||
``br-ex``, and so on.
|
||||
|
||||
To install 7.0 Controller in isolation from these networks, the script
|
||||
configures the deployment information for the node in a way that
|
||||
physical interfaces are not added to certain virtual bridges when
|
||||
OpenStack is being deployed.
|
||||
|
||||
This ensures that the Controller has no physical connection to Management
|
||||
and Public network.
|
||||
|
||||
Using Fuel for isolated deployment
|
||||
__________________________________
|
||||
|
||||
Fuel is responsible for the assignment of IP addresses to logical
|
||||
interfaces in the Management, Public and other types of networks.
|
||||
The environment cloning function in Nailgun API does copy the IP
|
||||
ranges and Virtual IP addressses of the original cluster.
|
||||
|
||||
Fuel configures Linux bridges and interfaces during the deployment of an
|
||||
environment. This configuration is managed by Puppet and is defined in
|
||||
the deployment settings. You can modify these settings to disable
|
||||
adding of certain physical interface to the bridge.
|
||||
|
||||
For deployment to succeed with the described schema, you need to ensure
|
||||
that no network checks break the installation by disabling a check for
|
||||
connectivity to the default gateway. Fuel installer expects the gateway
|
||||
to be in the Public network, which is not directly accessible from our
|
||||
isolated Controller.
|
||||
|
||||
The exact commands to create an isolated Upgrade Seed environment are
|
||||
listed in the :ref:`Upgrade Script <upg_script>` chapter.
|
||||
|
||||
Initial state of Ceph cluster
|
||||
_____________________________
|
||||
|
||||
According to the upgrade scenario, Ceph cluster must be installed in
|
||||
a way that allows for replacing the original Monitors of the 6.1
|
||||
environment with the new Monitors when 7.0 CICs take over. There is
|
||||
a way to install a cluster without OSD nodes and thus rule out the
|
||||
rebalance and data movement once the original OSD nodes start joining
|
||||
the cluster. However, it requires that the upload of the test VM image
|
||||
by Fuel is disabled before the deployment. We achieve this by
|
||||
disabling the corresponding tasks in the deployment graph:
|
||||
``upload_cirros`` and ``check_ceph_ready``.
|
||||
|
||||
Maintenance Mode
|
||||
++++++++++++++++
|
||||
|
||||
During the installation of 7.0 Seed cloud the original 6.1 environment
|
||||
continues to operate normally. Seed CIC do not interfere with the
|
||||
original CICs and the latter could continue the operation through
|
||||
the initial stages of the upgrade.
|
||||
|
||||
However, when it comes to the upgrade of state databases of
|
||||
OpenStack services, you need to make sure that no changes are made
|
||||
to the state data. Maintenance mode must be started before you download
|
||||
data from the state database of 6.1 OpenStack environment.
|
||||
Maintenance mode should last at least until the database upgrade is
|
||||
finished and 7.0 CICs take over the environment.
|
||||
|
||||
Note that Maintenance mode implemented according to these instructions
|
||||
does not impact operations of existing virtual server instances and
|
||||
other resources. It only affects OpenStack API endpoints which are the
|
||||
only way for the end user to change the state data of the cluster.
|
||||
|
||||
High Availability architecture of Mirantis OpenStack provides access to
|
||||
all OpenStack APIs at a single VIP address via HAProxy load balancer.
|
||||
You need to configure HAProxy server to return code ``HTTP 503`` on
|
||||
all requests to the services listening on the Public VIP in 6.1
|
||||
environment. This will not allow users to change the state of the
|
||||
virtual resources in the original cloud which can be lost after the
|
||||
data is downloaded from DB.
|
||||
|
||||
On 7.0 CIC, you must disable all OpenStack component services to make
|
||||
sure that they do not write to the state database while it is being
|
||||
upgraded. Otherwise, this might lead to data corruption and loss.
|
||||
|
||||
All the detailed commands used to put environments into Maintenance
|
||||
mode are listed in the Upgrade Script chapter below.
|
||||
|
||||
Upgrade databases
|
||||
+++++++++++++++++
|
||||
|
||||
Database upgrade is a standard procedure provided by OpenStack upstream
|
||||
as a main upgrade feature. It allows converting data from state
|
||||
databases of all OpenStack component services from a previous to a new
|
||||
release version schema. It is necessary to fully preserve the status of
|
||||
the virtual resources provided by the cloud through the upgrade
|
||||
procedure.
|
||||
|
||||
The data is dumped from MySQL database on one of the CIC nodes in 6.1
|
||||
environment. A text dump of the database is compressed and sent over
|
||||
to CIC node in 7.0 environment.
|
||||
|
||||
After uploading the data to MySQL on 7.0 CIC, use standard OpenStack
|
||||
methods to upgrade the database schema to the new release. Specific
|
||||
commands that upgrade the schema for particular components of the
|
||||
platform are listed in the Upgrade Script chapter below.
|
||||
|
||||
Configure Ceph Monitors
|
||||
+++++++++++++++++++++++
|
||||
|
||||
Architecture constraints for the upgrade procedure define that in the
|
||||
upgradeable configuration Ceph is used for all types of storage in the
|
||||
OpenStack platform: ephemeral storage, permanent storage, object
|
||||
storage and Glance image store. Ceph Monitors are essential for the
|
||||
Ceph cluster and must be upgraded seamlessly and transparently.
|
||||
|
||||
By default, Fuel installer creates a new Ceph cluster in the 7.0 Seed
|
||||
environment. You need to copy the configuration of the cluster from
|
||||
6.1 environment to override the default configuration. This will
|
||||
allow OSD nodes from 6.1 environment to switch to the new Monitors
|
||||
when 7.0 CICs take over the control plane of the upgraded environment.
|
||||
|
||||
The Upgrade Script synchronizes the configuration of Ceph Monitors in
|
||||
the 6.1 and 7.0 clusters during the upgrade procedure.
|
||||
|
||||
Upgrade Control Plane
|
||||
+++++++++++++++++++++
|
||||
|
||||
This step is called 'Upgrade', as it concludes with a new CIC of
|
||||
version 7.0 listening on the same set of IP addresses as the original
|
||||
6.1 CICs. However, from the technical standpoint it is more of a
|
||||
switch to a new version of control plane. 7.0 Controller takes over the
|
||||
Virtual IP addresses of 6.1 environment, while the original CICs are
|
||||
disconnected from all networks except Admin. The sections that follow
|
||||
explain what happens and why at every stage of the upgrade process.
|
||||
|
||||
Start OpenStack services on 7.0 Controller
|
||||
__________________________________________
|
||||
|
||||
As part of Maintenance mode, OpenStack component services were shut
|
||||
down on 7.0 CIC before upgrading the database. These services include
|
||||
Nova, Glance, Keystone, Neutron and Cinder. Now it is time to restore
|
||||
them with a new data set created by the database migration procedure.
|
||||
This operation basically reverts the shutdown operation described above.
|
||||
It is automated in the Upgrade Script.
|
||||
|
||||
Note that Neutron restart involves creation of tenant networking
|
||||
resources on CIC nodes where Neutron agents run. This process can
|
||||
take longer than starting all other services, so check it carefully
|
||||
before you proceed with the upgrade.
|
||||
|
||||
Delete ports on 6.1 Controllers
|
||||
_________________________________
|
||||
|
||||
Before 7.0 CIC can take over the virtual network addresses in the
|
||||
upgraded environment, you need to disconnect 6.1 CICs to release
|
||||
those addresses. Based on the CICs networking schema described above,
|
||||
to do that you need to delete patch ports from certain OVS bridges.
|
||||
|
||||
This procedure is automated by the upgrade script and executed as part
|
||||
of the ``upgrade-cics`` subcommand.
|
||||
|
||||
Connect 7.0 Controller
|
||||
______________________
|
||||
|
||||
After 6.1 CICs are disconnected from all networks in the environment,
|
||||
7.0 CIC can take over their former VIP addresses. The take-over
|
||||
procedure adds physical ports to the appropriate bridges and brings
|
||||
the ports up.
|
||||
|
||||
Upgrade hypervisor host
|
||||
+++++++++++++++++++++++
|
||||
|
||||
Hypervisor hosts provide their physical resources to run virtual
|
||||
machines. Physical resources are managed by hypervisor software,
|
||||
usually 'libvirt' and 'qemu-kvm' packages. With KVM hypervisor,
|
||||
all virtualization tasks are handled by the Linux kernel. Open vSwitch
|
||||
provides L2 network connectivity to virtual machines. All together,
|
||||
kernel, hypervisor and OVS constitute a data plane of Compute service.
|
||||
|
||||
You can upgrade data-plane software on a hypervisor host (or Compute
|
||||
node) by re-installing the operating system to a new version with Fuel
|
||||
installer. However, the deployment process takes time and impacts the
|
||||
virtual machines. To minimize the impact, leverage live migration to
|
||||
move all virtual machines from the Compute node before you start
|
||||
upgrading it. You can do that since Compute node's control plane is
|
||||
upgraded to 7.0.
|
||||
|
||||
Nailgun API extension installed by the Upgrade Script allows to move
|
||||
a node to the Upgrade Seed environment in runtime. It preserves the ID
|
||||
of the node, its hostname and configurations of its disks and
|
||||
interfaces.
|
||||
|
||||
When a node is added to the upgraded environment, the script provisions
|
||||
the node. When the provisioning is finished, the script runs the
|
||||
deployment of the node. As a result of the deployment, the node will
|
||||
be added to the environment as a fully capable Mirantis
|
||||
OpenStack 7.0 Compute node.
|
||||
|
||||
Upgrade of a single Compute node must be repeated for all the nodes
|
||||
of 6.1 environment in a rolling fashion. VMs must be gradually moved
|
||||
from the remaining 6.1 Compute nodes to the 7.0 ones with live
|
||||
migration.
|
||||
|
||||
Upgrade Ceph OSD node
|
||||
+++++++++++++++++++++
|
||||
|
||||
In a Ceph cluster all data is stored on OSD nodes. These nodes have one
|
||||
or more storage devices (or disk partitions) dedicated to Ceph data and
|
||||
run ceph-osd daemon that is responsible for I/O operations on Ceph data.
|
||||
|
||||
Upgrading OSD node via Fuel means that the node must be redeployed. Per
|
||||
the requirement to minimize end-user impact and the move of data across
|
||||
the OpenStack cluster being upgraded, we developed a procedure to
|
||||
redeploy Ceph OSD nodes with the original data set. Although Fuel
|
||||
by default erases all data from disks of the node it deploys, you can
|
||||
patch and configure the installer to keep Ceph data on the devices
|
||||
intact.
|
||||
|
||||
There are several stages of the deployment when the data is erased from
|
||||
all disks in the Ceph OSD node. First, when you delete a Ceph node,
|
||||
Nailgun agent on that node does the erasing on all non-removable disks
|
||||
by writing 0s to the first 10MB of every disk. Then, at the provisioning
|
||||
stage, Ubuntu installer creates partitions on disks and formats them
|
||||
according to the disks configuration provided by Fuel orchestration
|
||||
components.
|
||||
|
||||
As part of the upgrade procedure, we provide patches for the components
|
||||
involved in volumes management that allow to keep data on certain
|
||||
partitions or disks. These patches are applied automatically by the
|
||||
Upgrade Script.
|
||||
|
||||
Disable rebalance
|
||||
_________________
|
||||
|
||||
By default, Ceph initiates rebalance of data when OSD node goes down.
|
||||
Rebalancing means that the data of replicas is moved between the
|
||||
remaining nodes, which takes significant time and impacts end user's
|
||||
virtual machines and workloads. We disable the rebalance and
|
||||
recalculation of CRUSH maps when OSD node goes down. When a node is
|
||||
reinstalled, OSD connects to Ceph cluster with the original data set.
|
||||
|
||||
Finalizing the upgrade
|
||||
++++++++++++++++++++++
|
||||
|
||||
When all nodes are reassigned to the 7.0 environment and upgraded,
|
||||
it is time to finalize the upgrade procedure with a few steps that allow
|
||||
Fuel installer to manage with the upgraded environment just as with
|
||||
vanilla 7.0 environment, installed from scratch:
|
||||
|
||||
* revert all patches applied to Fuel components;
|
||||
* delete the original environment.
|
|
@ -0,0 +1,25 @@
|
|||
.. index:: Upgrade Script
|
||||
|
||||
.. _Upg_Script:
|
||||
|
||||
Upgrade Script Explained
|
||||
------------------------
|
||||
|
||||
In this chapter we explain how exactly we implement the steps described
|
||||
in :ref:`Solution Overview<upg_sol>`. Sections of this chapter contain
|
||||
appendices with listings of commands and scripts that implement each
|
||||
particular action.
|
||||
|
||||
.. IMPORTANT::
|
||||
|
||||
* All commands in this section must be executed on the Fuel Master
|
||||
node, unless specified otherwise.
|
||||
|
||||
* You must use Bourne shell (``bash``) to execute commands.
|
||||
|
||||
.. include:: /pages/operations/upgrade/3010-upgrade-prerequisites.rst
|
||||
.. include:: /pages/operations/upgrade/3020-prepare-fuel-master.rst
|
||||
.. include:: /pages/operations/upgrade/3030-clone-env-settings.rst
|
||||
.. include:: /pages/operations/upgrade/3040-install-seed.rst
|
||||
.. include:: /pages/operations/upgrade/3050-upgrade-cics.rst
|
||||
.. include:: /pages/operations/upgrade/3060-upgrade-node.rst
|
|
@ -0,0 +1,103 @@
|
|||
.. index:: Upgrade Prereq
|
||||
|
||||
.. _Upg_Prereq:
|
||||
|
||||
Upgrade Prerequisites
|
||||
+++++++++++++++++++++
|
||||
|
||||
There are certain prerequisites for upgrading Mirantis OpenStack
|
||||
environment managed by Fuel installer. You need to make sure that
|
||||
all the requirements are met before proceeding with the procedure.
|
||||
This section describes prerequisites and gives a list of commands used
|
||||
to check if the requirements are met.
|
||||
|
||||
Versions of Fuel installer and environment
|
||||
__________________________________________
|
||||
|
||||
First, you need to check the versions of Fuel installer and the
|
||||
environment you've picked for the upgrade. Version of Fuel must be
|
||||
equal to 7.0. Version of environment must be equal to 6.1. You
|
||||
can check versions using the Fuel Web UI or CLI client to Fuel API.
|
||||
|
||||
Configuration of environment
|
||||
____________________________
|
||||
|
||||
The configuration of the environment picked for the upgrade must
|
||||
comply to the architecture constraints for the upgrade procedure.
|
||||
You can check the applicability of the procedure to your configuration
|
||||
via Fuel Web UI.
|
||||
|
||||
Check Upgrade Prerequisites
|
||||
___________________________
|
||||
|
||||
*Pick environment to upgrade*
|
||||
|
||||
Select an environment to upgrade from the list of environments in
|
||||
Fuel CLI and assign its ID to the ``ORIG_ID`` variable.
|
||||
|
||||
::
|
||||
|
||||
fuel env
|
||||
<select from list of environments>
|
||||
export ORIG_ID=<enter ID of environment here>
|
||||
|
||||
*Check installer version in Fuel Web UI*
|
||||
|
||||
Open the Fuel Web UI in your browser, log in and check the version
|
||||
number of Fuel installer in the lower right corner of the page:
|
||||
|
||||
.. image:: /_images/upgrade/fuel-version-check.png
|
||||
|
||||
*Check installer version in Fuel CLI*
|
||||
|
||||
Run the following command on your Fuel Master node to verify the
|
||||
version of the Fuel installer:
|
||||
|
||||
::
|
||||
|
||||
fuel release | grep available | grep -o 2015.1-7.0
|
||||
|
||||
You must see the following lines in the output:
|
||||
|
||||
::
|
||||
|
||||
2015.1-7.0
|
||||
2015.1-7.0
|
||||
|
||||
*Check environment version on the Fuel Web UI*
|
||||
|
||||
Click on the environment you've picked for the upgrade. Check the
|
||||
environment version in the status line above the list of nodes:
|
||||
|
||||
.. image:: /_images/upgrade/env-version-check.png
|
||||
|
||||
*Check environment version in Fuel CLI*
|
||||
|
||||
Run the following command on your Fuel Master node to verify the
|
||||
version of the environment you pick for the upgrade:
|
||||
|
||||
::
|
||||
|
||||
fuel env | awk -F\| '$1~/'$ORIG_ID'/{print $5}' | tr -d ' ' \
|
||||
| xargs -I@ bash -c "fuel release | awk -F\| '\$1~/@/{print \$5}'" | tr -d ' '
|
||||
|
||||
You must see the following line in the output:
|
||||
|
||||
::
|
||||
|
||||
2014.2.2-6.1
|
||||
|
||||
*Check configuration of environment*
|
||||
|
||||
You need to open the Fuel Web UI in your browser. Log in, click on the
|
||||
environment you'd like to upgrade and select the *Settings* tab. Check
|
||||
the following fields and verify they contain the values:
|
||||
|
||||
* Hypervisor type: **KVM**
|
||||
* Ceph RBD for volumes: **Enabled**
|
||||
* Ceph RBD for images: **Enabled**
|
||||
* Ceph RBD for ephemeral volumes: **Enabled**
|
||||
* Ceph RadosGW for objects: **Enabled**
|
||||
|
||||
Navigate to the *Networks* tab and check the second line after the tab
|
||||
title. It must state *Neutron with VLAN segmentation*.
|
|
@ -0,0 +1,49 @@
|
|||
.. index:: Prep Fuel
|
||||
|
||||
.. _Upg_Prep:
|
||||
|
||||
Prepare Fuel Master
|
||||
+++++++++++++++++++
|
||||
|
||||
Before you start the upgrade procedure, you must prepare your Fuel
|
||||
installer. There are several changes to the default behavior and
|
||||
configuration of installer that the upgrade functions depend on.
|
||||
The configuration changes include installation of additional packages
|
||||
and setting environment variables.
|
||||
|
||||
In this section we briefly describe which components are affected by
|
||||
the change and why, and explain how to apply the patches correctly.
|
||||
Explanations of specific patches and their purpose will be given below
|
||||
in the sections dedicated to the steps that make use of those patches:
|
||||
|
||||
Install the Upgrade Script
|
||||
__________________________
|
||||
|
||||
The upgrade logic is automated in the script named ``octane``.
|
||||
You need to download and install this script from RPM repository
|
||||
on your Fuel Master node.
|
||||
|
||||
Prepare environment variables
|
||||
_____________________________
|
||||
|
||||
There are several variables that need to be set before you start
|
||||
the upgrade procedure. They will be used throughout the whole process.
|
||||
These variables include the ID and name of the environment picked
|
||||
for the upgrade.
|
||||
|
||||
.. _upgrade-patch-commands:
|
||||
|
||||
Commands To Prepare The Fuel Master Node
|
||||
________________________________________
|
||||
|
||||
Install the ``octane`` application using ``yum`` package manager:
|
||||
|
||||
::
|
||||
|
||||
yum install -y fuel-octane
|
||||
|
||||
The upgrade script prepares the Fuel Master node with a single command:
|
||||
|
||||
::
|
||||
|
||||
octane prepare
|
|
@ -0,0 +1,28 @@
|
|||
.. index:: Clone Env
|
||||
|
||||
.. _Upg_Clone:
|
||||
|
||||
Clone Environment settings
|
||||
++++++++++++++++++++++++++
|
||||
|
||||
During the upgrade, the new Fuel environment of version 7.0
|
||||
will be created with a copy of Network parameters and Settings
|
||||
from the upgrade target environment of version 6.1. The generated
|
||||
configurations, like credentials of the service users, are also copied
|
||||
from the original environment wherever possible.
|
||||
|
||||
Environment clone command
|
||||
_________________________
|
||||
|
||||
Run the following command to create Upgrade Seed environment:
|
||||
|
||||
::
|
||||
|
||||
octane upgrade-env ${ORIG_ID}
|
||||
|
||||
Store the ID of the Upgrade Seed environment displayed as a result of this
|
||||
command into variable:
|
||||
|
||||
::
|
||||
|
||||
export SEED_ID=<ID>
|
|
@ -0,0 +1,53 @@
|
|||
.. index:: Install Seed
|
||||
|
||||
.. _Upg_Seed:
|
||||
|
||||
Install Controller
|
||||
++++++++++++++++++
|
||||
|
||||
Installation of CIC node is performed by standard Fuel installer
|
||||
actions and is split into two distinct steps.
|
||||
|
||||
#. Prepare nodes settings and use the provisioning feature of
|
||||
Fuel to install an operating system and configure disks on nodes.
|
||||
#. Make modifications to the deployment information of the environment
|
||||
that affects all CIC nodes, and deploy OpenStack platform onto them.
|
||||
|
||||
Modified deployment settings
|
||||
____________________________
|
||||
|
||||
To deploy a 7.0 CIC node properly, we need to prepare deployment
|
||||
information to make Fuel configure nodes and OpenStack services
|
||||
with the following modifications:
|
||||
|
||||
#. Disable checking access to the default gateway in Public network
|
||||
#. Skip adding physical interfaces to Linux bridges
|
||||
#. Skip creation of the 'default' Fuel-defined networks in Neutron
|
||||
#. Change default gateway addresses to the address of the Fuel Master node
|
||||
|
||||
Deployment settings can be downloaded from Fuel API as a set of files.
|
||||
The upgrade script updates the settings by changing those files and
|
||||
uploading the modified information back via Fuel API.
|
||||
|
||||
The upgrade script keeps the deployment infromation for the environment
|
||||
in a cache directory (by default, ``/tmp/octane/deployment``). The
|
||||
deployment settings for the nodes are stored to subdirectory
|
||||
``deployment_<cluster-id>``, where ``<cluster-id>`` is an ID of
|
||||
the environment.
|
||||
|
||||
The deployment tasks are kept in subdirectory ``cluster_<cluster-id>``
|
||||
of the same cache directory. You can use them to check that the
|
||||
deployment is properly configured.
|
||||
|
||||
Install Controller commands
|
||||
___________________________
|
||||
|
||||
The upgrade automation script allows upgrading a contorller that
|
||||
exists in the original 6.1 environment. Select which controller
|
||||
you would like to upgrade and run the following command. Replace
|
||||
``<NODE-ID>`` with the actual ID of 6.1 Controller you'd like to
|
||||
upgrade:
|
||||
|
||||
::
|
||||
|
||||
./octane upgrade-node ${SEED_ID} isolated <NODE-ID>
|
|
@ -0,0 +1,93 @@
|
|||
.. index:: Upgrade Controllers
|
||||
|
||||
.. _Upg_CICs:
|
||||
|
||||
Switch to 7.0 Control Plane
|
||||
+++++++++++++++++++++++++++
|
||||
|
||||
To switch the Controller services, the script transfers state
|
||||
data for those services from the original Controllers to 7.0
|
||||
Seed Controllers and swaps the Controllers connections to the
|
||||
Management and External networks.
|
||||
|
||||
Maintenance mode
|
||||
________________
|
||||
|
||||
To prevent the loss of data in OpenStack state database, API
|
||||
interaction with the environment must be disabled. This mode
|
||||
of operations is also known as :ref:`Maintenance Mode <db-backup-ops>`.
|
||||
|
||||
In maintenance mode, all services that write to DB are disabled. All
|
||||
communications to the control plane of the cluster are also disabled.
|
||||
VMs and other virtual resources must be able to continue to operate as
|
||||
usual.
|
||||
|
||||
.. note::
|
||||
|
||||
The Maintenance Mode is automatically set up by the Upgrade Script
|
||||
as soon as you start the upgrade of the state database. Make sure
|
||||
to carefully plan the maintenance window for that time and inform
|
||||
your users in advance.
|
||||
|
||||
Database migration
|
||||
__________________
|
||||
|
||||
Before the databases could be upgraded, all OpenStack services on
|
||||
7.0 Controller must be stopped to prevent corruption of the metadata.
|
||||
The upgrade script uses standard Ubuntu startup scripts from
|
||||
``/etc/init.d`` on controllers to shut off the services.
|
||||
|
||||
Databases are dumped in text format from MySQL server on 6.1 CIC,
|
||||
copied to 7.0 CIC, and uploaded to the upgraded MySQL server. Standard
|
||||
OpenStack tools allow to upgrade the structure of databases saving the
|
||||
data itself via sqlalchemy-powered DB migrations.
|
||||
|
||||
Run the following command to set up Maintenance Mode and immediately
|
||||
start upgrading the state databases of OpenStack services:
|
||||
|
||||
::
|
||||
|
||||
octane upgrade-db ${ORIG_ID} ${SEED_ID}
|
||||
|
||||
Upgrade Ceph cluster
|
||||
____________________
|
||||
|
||||
To replace Ceph Monitors on the same IP addresses, the upgrade script
|
||||
must preserve the cluster's identity and auth parameters. It copies the
|
||||
configuration files, keyrings and state dirs from 6.1 CICs to 7.0 CICs
|
||||
and uses Ceph management tools to restore cluster identity.
|
||||
|
||||
Run the following command to replicate the configuration of the Ceph
|
||||
cluster:
|
||||
|
||||
::
|
||||
|
||||
octane upgrade-ceph ${ORIG_ID} ${SEED_ID}
|
||||
|
||||
Upgrade CICs
|
||||
____________
|
||||
|
||||
The following section describes the procedure for replacing Controllers
|
||||
from 6.1 environment with the Controllers from 7.0 environment
|
||||
and then upgrading the 6.1 Controllers.
|
||||
|
||||
When the DB upgrade is finished, all OpenStack services on 7.0 CIC are
|
||||
started using Pacemaker and Upstart. Then the upgrade script disconnects
|
||||
the 6.1 CICs from the Management and Public networks by removing patch
|
||||
ports between the logical interfaces to the respective networks and
|
||||
physical interfaces connected to the network media.
|
||||
|
||||
On 7.0 CIC, the physical interface must be added to the Linux bridge
|
||||
corresponding to the Management network. This allows the Compute nodes
|
||||
to transparently switch from the old to the upgraded control plane
|
||||
without the need to reconfigure and renumber every service.
|
||||
|
||||
Commands to switch the Control Plane
|
||||
____________________________________
|
||||
|
||||
Run the following command to switch from 6.1 to 7.0 Control Plane:
|
||||
|
||||
::
|
||||
|
||||
octane upgrade-control ${ORIG_ID} ${SEED_ID}
|
||||
|
|
@ -0,0 +1,105 @@
|
|||
.. index:: Upgrade Node
|
||||
|
||||
.. _Upg_Node:
|
||||
|
||||
Upgrade Node
|
||||
++++++++++++
|
||||
|
||||
Node upgrade is essentially a reinstallation of an operating system
|
||||
and OpenStack platform services. We need to delete a node from the
|
||||
6.1 environment and assign it to 7.0 Seed environment, then provision
|
||||
it and deploy OpenStack on it.
|
||||
|
||||
By default, Fuel installer erases all data from the disks on the node,
|
||||
creates new partitions structure, installs an operating system and
|
||||
deploys OpenStack.
|
||||
|
||||
Depending on the roles the node has in the 6.1 environment,
|
||||
we might need to make changes to the behavior. For example,
|
||||
to upgrade Ceph OSD node, we need to make Fuel keep data on Ceph
|
||||
partitions of that node. To upgrade Compute nodes, we need to use
|
||||
live migration to move users' VMs from it to other hypervisor
|
||||
hosts. There are also several steps in the upgrade procedure that are
|
||||
common to both supported roles ('compute' and 'ceph-osd'). This section
|
||||
describes these common steps to upgrade a node and how to use the
|
||||
Upgrade Script to upgrade a node with any of the supported roles.
|
||||
|
||||
Prepare Ceph OSD node to upgrade
|
||||
________________________________
|
||||
|
||||
Preparations for the upgrade of Ceph OSD node include steps to minimize
|
||||
data transfers inside the Ceph cluster during the upgrade. They also
|
||||
aim to ensure that the data on OSD devices is kept intact.
|
||||
|
||||
From the impact standpoint, the most optimal solution is to minimize
|
||||
data transfers over network during the upgrade of Ceph cluster.
|
||||
Ceph will normally rebalance its data when OSD node is down. However,
|
||||
since the described procedure preserves Ceph data on the node,
|
||||
rebalance must be turned off. We use the standard Ceph flag ``noout``
|
||||
to disable the rebalance on a node outage.
|
||||
|
||||
Prepare Compute node to upgrade
|
||||
_______________________________
|
||||
|
||||
Compute node runs virtual machines in hypervisor processes.
|
||||
To satisfy the requirement to minimize the downtime of virtual
|
||||
resources, we must ensure that the VMs are moved from the node
|
||||
in preparation for the reinstallation. The move must be
|
||||
done with the most seamless migration method available.
|
||||
This move is referred to as **evacuation**.
|
||||
|
||||
Using Ceph shared storage for the Nova instance's ephemeral
|
||||
disk allows using live migration of virtual instances. The sections
|
||||
below describe the steps required to live migrate all VMs from the
|
||||
hypervisor host picked for the upgrade.
|
||||
|
||||
To minimize the impact of the upgrade procedure on the end user
|
||||
workloads, we need to migrate all VMs off the hypervisor picked for
|
||||
the upgrade and make sure that no new VMs are provisioned to that host.
|
||||
Scheduling to the host can be ruled out by disabling Compute service on
|
||||
that host. This does not affect the ability to migrate VMs from that
|
||||
host.
|
||||
|
||||
Reassign node to Seed environment
|
||||
_________________________________
|
||||
|
||||
There is an ``/api/cluster/<:id>/upgrade`` extension to the Fuel API
|
||||
that allows moving a node from an environment the its Upgrade Seed. So
|
||||
the reassignment is a matter of a single call to the Fuel API from the
|
||||
Upgrade Script.
|
||||
|
||||
Note that with this extension the reassigned node will not change its
|
||||
ID or host name.
|
||||
|
||||
Verify node upgrade
|
||||
___________________
|
||||
|
||||
After the successful installation you need to make sure that the node
|
||||
is connected to CICs properly, according to its role. Ceph OSD node
|
||||
must be ``up`` in the OSD tree. The Compute node must be connected to
|
||||
the Nova controller services. Below in the list of commands you will
|
||||
find how to check these requirements.
|
||||
|
||||
Node Upgrade command
|
||||
____________________
|
||||
|
||||
Run the following command to upgrade a node identified by the ``NODE_ID``
|
||||
parameter:
|
||||
|
||||
::
|
||||
|
||||
octane upgrade-node ${SEED_ID} ${NODE_ID}
|
||||
|
||||
You can upgrade more than one node at a time. Run the following command
|
||||
to upgrade multiple nodes identified by the ``NODE_ID1``, ``NODE_ID2``,
|
||||
and ``NODE_ID3`` parameters:
|
||||
|
||||
::
|
||||
|
||||
octane upgrade-node ${SEED_ID} ${NODE_ID1} ${NODE_ID2} ${NODE_ID3}
|
||||
|
||||
.. note::
|
||||
|
||||
Pay attention to the replication factor of your Ceph cluster and
|
||||
do not upgrade more Ceph OSD nodes than the value of the replication
|
||||
factor minus one.
|
|
@ -0,0 +1,62 @@
|
|||
.. index:: Finalize Upgrade
|
||||
|
||||
.. _Upg_Final:
|
||||
|
||||
Finalize Upgrade
|
||||
----------------
|
||||
|
||||
This chapter contains actions required to finalize the upgrade procedure
|
||||
on an environment and on Fuel installer in general. Finalization
|
||||
involves the following steps:
|
||||
|
||||
* Restore the source code of the components of the installer by
|
||||
reverting the patches that implement modifications to the
|
||||
installer's behavior.
|
||||
* Delete the original 6.1 environment and release the original
|
||||
controller nodes.
|
||||
|
||||
See the sections below for the detailed description of how to do that
|
||||
and the list of commands:
|
||||
|
||||
* :ref:`Uninstall upgrade-related components <upgrade-cleanup-revert>`
|
||||
* :ref:`Decommission environment <upgrade-cleanup-delete-env>`
|
||||
|
||||
.. _upgrade-cleanup-revert:
|
||||
|
||||
Revert Patches
|
||||
++++++++++++++
|
||||
|
||||
The final goal of the upgrade procedure is to get the upgraded
|
||||
environment as close as possible to the environment installed with
|
||||
the new release version and retain the ability to manage it in the new
|
||||
version of Fuel installer.
|
||||
|
||||
To return the Fuel Master node into original state, we just need to uninstall
|
||||
components that we installed for the upgrade purposes, specifically, extension
|
||||
to ``fuelclient`` CLI command that is used to call Upgrade extension in the
|
||||
Fuel API.
|
||||
|
||||
Commands uninstall components
|
||||
_____________________________
|
||||
|
||||
Run the following command to revert the changes made to the source
|
||||
code and configuration of components of the Fuel installer::
|
||||
|
||||
octane cleanup-fuel
|
||||
|
||||
.. _upgrade-cleanup-delete-env:
|
||||
|
||||
Delete 6.1 environment
|
||||
++++++++++++++++++++++++
|
||||
|
||||
Delete the original 6.1 environment to release the Controller nodes
|
||||
and completely switch to use the 7.0 environment instead.
|
||||
|
||||
.. note::
|
||||
|
||||
The following operation may cause data loss if your upgrade
|
||||
operation was not completed successfully. Proceed with caution.
|
||||
|
||||
::
|
||||
|
||||
fuel env --env $ORIG_ID --delete
|
|
@ -9,6 +9,7 @@ Terminology Reference
|
|||
.. include:: /pages/terminology/b/bonding.rst
|
||||
.. include:: /pages/terminology/c/ceilometer.rst
|
||||
.. include:: /pages/terminology/c/ceph.rst
|
||||
.. include:: /pages/terminology/c/cic.rst
|
||||
.. include:: /pages/terminology/c/cinder.rst
|
||||
.. include:: /pages/terminology/c/cobbler.rst
|
||||
.. include:: /pages/terminology/c/compute-nodes.rst
|
||||
|
|
|
@ -0,0 +1,10 @@
|
|||
.. _cic-term:
|
||||
|
||||
CIC
|
||||
---
|
||||
CIC is a shorthand abbreviation for OpenStack :ref:`Controller
|
||||
node<controller-node-term>`: Cloud Infrastructure Controller.
|
||||
|
||||
For more information:
|
||||
|
||||
- :ref:`controller-arch` describes architecture of controller system.
|
Loading…
Reference in New Issue