openstack/charm-deployment-guide
Code Issues Proposed changes

Review deploy guide install OpenStack page

Browse Source 
This is the fourth of an intended comprehensive series
of reviews for the deploy guide.

A correction was made to how Ceph was configured as the
backend for Cinder. The 'cinder-ceph' charm is now used.

Some drive-by improvements re formatting in recently
reviewed files.

IP addresses have been obfuscated.

The admin password is now generated.

Change-Id: I259e5349c835d67238b7b3c592246039464e4f41
This commit is contained in:
Peter Matulis 2019-12-03 00:26:17 -05:00
parent e66040dc7e
commit 1b3338d937
7 changed files with 518 additions and 405 deletions
Show Stats Download Patch File Download Diff File Expand all files Collapse all files

14
deploy-guide/source/install-juju.rst
View File

@ -15,7 +15,7 @@ Install Juju
To install Juju: To install Juju:
.. code-block:: console .. code-block:: none
sudo snap install juju --classic sudo snap install juju --classic
@ -31,14 +31,14 @@ this via a cloud definition file, such as ``maas-cloud.yaml``:
mymaas: mymaas:
type: maas type: maas
auth-types: [oauth1] auth-types: [oauth1]
endpoint: http://10.0.0.2:5240/MAAS endpoint: http://10.0.0.3:5240/MAAS
We've called the cloud 'mymaas' and its endpoint is based on the IP address of We've called the cloud 'mymaas' and its endpoint is based on the IP address of
the MAAS system. the MAAS system.
The cloud is added in this way: The cloud is added in this way:
.. code-block:: console .. code-block:: none
juju add-cloud --client -f maas-cloud.yaml mymaas juju add-cloud --client -f maas-cloud.yaml mymaas
@ -67,7 +67,7 @@ file ``~/admin-api-key`` on the MAAS system during the :ref:`Install MAAS
The credentials are added in this way: The credentials are added in this way:
.. code-block:: console .. code-block:: none
juju add-credential --client -f maas-creds.yaml mymaas juju add-credential --client -f maas-creds.yaml mymaas
@ -80,7 +80,7 @@ Create the Juju controller
We can now create the controller for the 'mymaas' cloud, and have called it We can now create the controller for the 'mymaas' cloud, and have called it
'maas-controller': 'maas-controller':
.. code-block:: console .. code-block:: none
juju bootstrap --constraints tags=juju mymaas maas-controller juju bootstrap --constraints tags=juju mymaas maas-controller
@ -101,14 +101,14 @@ The OpenStack deployment will be placed in its own Juju model for
organisational purposes. It will be called 'openstack'. Create the model, and organisational purposes. It will be called 'openstack'. Create the model, and
switch to it, with this one command: switch to it, with this one command:
.. code-block:: console .. code-block:: none
juju add-model openstack juju add-model openstack
The output of the :command:`juju status` command summarises the Juju aspect of The output of the :command:`juju status` command summarises the Juju aspect of
the environment. It should now look very similar to this: the environment. It should now look very similar to this:
.. code-block:: console .. code-block:: none
Model Controller Cloud/Region Version SLA Timestamp Model Controller Cloud/Region Version SLA Timestamp
openstack maas-controller mymaas/default 2.7.0 unsupported 04:28:49Z openstack maas-controller mymaas/default 2.7.0 unsupported 04:28:49Z

15
deploy-guide/source/install-maas.rst
View File

@ -40,8 +40,9 @@ type.
MAAS is also considered to be the sole provider of DHCP and DNS for the network MAAS is also considered to be the sole provider of DHCP and DNS for the network
hosting the MAAS cluster. hosting the MAAS cluster.
The MAAS system's single network interface resides on subnet **10.0.0.0/24** The MAAS system's single network interface resides on subnet
and the system itself has an assigned IP address of **10.0.0.2**. **10.0.0.0/21** and the system itself has an assigned IP address of
**10.0.0.3**.
.. attention:: .. attention::
@ -56,12 +57,12 @@ Here is a concise summary of how to install and initialise MAAS on the
designated system but make sure to consult the official `MAAS installation designated system but make sure to consult the official `MAAS installation
instructions`_ for details: instructions`_ for details:
.. code-block:: console .. code-block:: none
sudo apt-add-repository -y ppa:maas/2.6 sudo apt-add-repository -y ppa:maas/2.6
sudo apt install -y maas sudo apt install -y maas
sudo maas init --admin-username admin --admin-password ubuntu \ sudo maas init --admin-username admin --admin-password ubuntu \
--admin-email admin@example.com --admin-ssh-import <username> --admin-email admin@example.com --admin-ssh-import <username>
sudo maas-region apikey --username=admin > ~/admin-api-key sudo maas-region apikey --username=admin > ~/admin-api-key
See :command:`maas init --help` for details. See :command:`maas init --help` for details.
@ -94,7 +95,11 @@ MAAS administrator are:
| Password: **ubuntu** | Password: **ubuntu**
| |
The web UI can now be accessed here: **http://10.0.0.2:5240/MAAS** In this example, the address of the MAAS system is 10.0.0.3.
The web UI URL then becomes:
**http://10.0.0.3:5240/MAAS**
You will be whisked through an on-boarding process when you access the web UI You will be whisked through an on-boarding process when you access the web UI
for the first time. Recall that we require 18.04 LTS AMD64 images. for the first time. Recall that we require 18.04 LTS AMD64 images.

2
deploy-guide/source/install-openstack-bundle.rst
View File

@ -24,7 +24,7 @@ great detail in its Charm Store entry here: `openstack-base`_.
Once the bundle configuration has been confirmed OpenStack can be deployed: Once the bundle configuration has been confirmed OpenStack can be deployed:
.. code-block:: console .. code-block:: none
juju deploy /path/to/bundle/file juju deploy /path/to/bundle/file

133
deploy-guide/source/install-openstack-juju-status.rst Normal file
View File

@ -0,0 +1,133 @@
:orphan:
.. _install_openstack_juju_status:
===============
OpenStack cloud
===============
The below :command:`juju status --relations` output represents the cloud
installed from the instructions given on the :doc:`Install OpenStack
<install-openstack>` page.
.. code-block:: ini
Model Controller Cloud/Region Version SLA Timestamp
openstack maas-controller mymaas/default 2.7.0 unsupported 21:02:58Z
App Version Status Scale Charm Store Rev OS Notes
ceph-mon 14.2.2 active 3 ceph-mon jujucharms 44 ubuntu
ceph-osd 14.2.2 active 4 ceph-osd jujucharms 294 ubuntu
cinder 15.0.0 active 1 cinder jujucharms 297 ubuntu
cinder-ceph 15.0.0 active 1 cinder-ceph jujucharms 251 ubuntu
glance 19.0.0 active 1 glance jujucharms 291 ubuntu
keystone 16.0.0 active 1 keystone jujucharms 309 ubuntu
mysql 5.7.20 active 1 percona-cluster jujucharms 281 ubuntu
neutron-api 15.0.0 active 1 neutron-api jujucharms 282 ubuntu
neutron-gateway 15.0.0 active 1 neutron-gateway jujucharms 276 ubuntu
neutron-openvswitch 15.0.0 active 3 neutron-openvswitch jujucharms 269 ubuntu
nova-cloud-controller 20.0.0 active 1 nova-cloud-controller jujucharms 339 ubuntu
nova-compute 20.0.0 active 3 nova-compute jujucharms 309 ubuntu
ntp 3.2 active 4 ntp jujucharms 36 ubuntu
openstack-dashboard 13.0.2 active 1 openstack-dashboard jujucharms 297 ubuntu
placement 2.0.0 active 1 placement jujucharms 0 ubuntu
rabbitmq-server 3.6.10 active 1 rabbitmq-server jujucharms 97 ubuntu
Unit Workload Agent Machine Public address Ports Message
ceph-mon/0* active idle 1/lxd/1 10.0.0.21 Unit is ready and clustered
ceph-mon/1 active idle 2/lxd/3 10.0.0.22 Unit is ready and clustered
ceph-mon/2 active idle 3/lxd/1 10.0.0.23 Unit is ready and clustered
ceph-osd/0 active idle 0 10.0.0.27 Unit is ready (1 OSD)
ntp/2 active idle 10.0.0.27 123/udp chrony: Ready
ceph-osd/1 active idle 1 10.0.0.26 Unit is ready (1 OSD)
ntp/1 active idle 10.0.0.26 123/udp chrony: Ready
ceph-osd/2* active idle 2 10.0.0.28 Unit is ready (1 OSD)
ntp/0* active idle 10.0.0.28 123/udp chrony: Ready
ceph-osd/3 active idle 3 10.0.0.255 Unit is ready (1 OSD)
ntp/3 active idle 10.0.0.255 123/udp chrony: Ready
cinder/0* active idle 1/lxd/2 10.0.0.24 8776/tcp Unit is ready
cinder-ceph/0* active idle 10.0.0.24 Unit is ready
glance/0* active idle 2/lxd/2 10.0.0.20 9292/tcp Unit is ready
keystone/0* active idle 3/lxd/0 10.0.0.29 5000/tcp Unit is ready
mysql/0* active idle 0/lxd/0 10.0.0.8 3306/tcp Unit is ready
neutron-api/0* active idle 1/lxd/0 10.0.0.7 9696/tcp Unit is ready
neutron-gateway/0* active idle 0 10.0.0.27 Unit is ready
nova-cloud-controller/0* active idle 2/lxd/0 10.0.0.10 8774/tcp,8775/tcp Unit is ready
nova-compute/0 active idle 1 10.0.0.26 Unit is ready
neutron-openvswitch/2 active idle 10.0.0.26 Unit is ready
nova-compute/1* active idle 2 10.0.0.28 Unit is ready
neutron-openvswitch/0* active idle 10.0.0.28 Unit is ready
nova-compute/2 active idle 3 10.0.0.255 Unit is ready
neutron-openvswitch/1 active idle 10.0.0.255 Unit is ready
openstack-dashboard/0* active idle 3/lxd/2 10.0.0.14 80/tcp,443/tcp Unit is ready
placement/0* active idle 2/lxd/1 10.0.0.11 8778/tcp Unit is ready
rabbitmq-server/0* active idle 0/lxd/1 10.0.0.9 5672/tcp Unit is ready
Machine State DNS Inst id Series AZ Message
0 started 10.0.0.27 virt-node-03 bionic default Deployed
0/lxd/0 started 10.0.0.8 juju-218d08-0-lxd-0 bionic default Container started
0/lxd/1 started 10.0.0.9 juju-218d08-0-lxd-1 bionic default Container started
1 started 10.0.0.26 virt-node-02 bionic default Deployed
1/lxd/0 started 10.0.0.7 juju-218d08-1-lxd-0 bionic default Container started
1/lxd/1 started 10.0.0.21 juju-218d08-1-lxd-1 bionic default Container started
1/lxd/2 started 10.0.0.24 juju-218d08-1-lxd-2 bionic default Container started
2 started 10.0.0.28 virt-node-04 bionic default Deployed
2/lxd/0 started 10.0.0.10 juju-218d08-2-lxd-0 bionic default Container started
2/lxd/1 started 10.0.0.11 juju-218d08-2-lxd-1 bionic default Container started
2/lxd/2 started 10.0.0.20 juju-218d08-2-lxd-2 bionic default Container started
2/lxd/3 started 10.0.0.22 juju-218d08-2-lxd-3 bionic default Container started
3 started 10.0.0.255 virt-node-01 bionic default Deployed
3/lxd/0 started 10.0.0.29 juju-218d08-3-lxd-0 bionic default Container started
3/lxd/1 started 10.0.0.23 juju-218d08-3-lxd-1 bionic default Container started
3/lxd/2 started 10.0.0.14 juju-218d08-3-lxd-2 bionic default Container started
Relation provider Requirer Interface Type Message
ceph-mon:client cinder-ceph:ceph ceph-client regular
ceph-mon:client glance:ceph ceph-client regular
ceph-mon:client nova-compute:ceph ceph-client regular
ceph-mon:mon ceph-mon:mon ceph peer
ceph-mon:osd ceph-osd:mon ceph-osd regular
ceph-osd:juju-info ntp:juju-info juju-info subordinate
cinder-ceph:storage-backend cinder:storage-backend cinder-backend subordinate
cinder:cinder-volume-service nova-cloud-controller:cinder-volume-service cinder regular
cinder:cluster cinder:cluster cinder-ha peer
glance:cluster glance:cluster glance-ha peer
glance:image-service cinder:image-service glance regular
glance:image-service nova-cloud-controller:image-service glance regular
glance:image-service nova-compute:image-service glance regular
keystone:cluster keystone:cluster keystone-ha peer
keystone:identity-service cinder:identity-service keystone regular
keystone:identity-service glance:identity-service keystone regular
keystone:identity-service neutron-api:identity-service keystone regular
keystone:identity-service nova-cloud-controller:identity-service keystone regular
keystone:identity-service openstack-dashboard:identity-service keystone regular
keystone:identity-service placement:identity-service keystone regular
mysql:cluster mysql:cluster percona-cluster peer
mysql:shared-db cinder:shared-db mysql-shared regular
mysql:shared-db glance:shared-db mysql-shared regular
mysql:shared-db keystone:shared-db mysql-shared regular
mysql:shared-db neutron-api:shared-db mysql-shared regular
mysql:shared-db nova-cloud-controller:shared-db mysql-shared regular
mysql:shared-db placement:shared-db mysql-shared regular
neutron-api:cluster neutron-api:cluster neutron-api-ha peer
neutron-api:neutron-api nova-cloud-controller:neutron-api neutron-api regular
neutron-api:neutron-plugin-api neutron-gateway:neutron-plugin-api neutron-plugin-api regular
neutron-api:neutron-plugin-api neutron-openvswitch:neutron-plugin-api neutron-plugin-api regular
neutron-gateway:cluster neutron-gateway:cluster quantum-gateway-ha peer
neutron-gateway:quantum-network-service nova-cloud-controller:quantum-network-service quantum regular
neutron-openvswitch:neutron-plugin nova-compute:neutron-plugin neutron-plugin subordinate
nova-cloud-controller:cluster nova-cloud-controller:cluster nova-ha peer
nova-compute:cloud-compute nova-cloud-controller:cloud-compute nova-compute regular
nova-compute:compute-peer nova-compute:compute-peer nova peer
ntp:ntp-peers ntp:ntp-peers ntp peer
openstack-dashboard:cluster openstack-dashboard:cluster openstack-dashboard-ha peer
placement:cluster placement:cluster openstack-ha peer
placement:placement nova-cloud-controller:placement placement regular
rabbitmq-server:amqp cinder:amqp rabbitmq regular
rabbitmq-server:amqp glance:amqp rabbitmq regular
rabbitmq-server:amqp neutron-api:amqp rabbitmq regular
rabbitmq-server:amqp neutron-gateway:amqp rabbitmq regular
rabbitmq-server:amqp neutron-openvswitch:amqp rabbitmq regular
rabbitmq-server:amqp nova-cloud-controller:amqp rabbitmq regular
rabbitmq-server:amqp nova-compute:amqp rabbitmq regular
rabbitmq-server:cluster rabbitmq-server:cluster rabbitmq-ha peer

759
deploy-guide/source/install-openstack.rst
View File

@ -1,31 +1,20 @@
=================
Install OpenStack Install OpenStack
================= =================
Now that we've installed and configured :doc:`MAAS <install-maas>` and In the :doc:`previous section <install-juju>`, we installed Juju and created a
successfully deployed a :doc:`Juju <install-juju>` controller, it's time to Juju controller and model. We are now going to use Juju to install OpenStack
do some real work; use Juju to deploy itself. There are two methods to choose from:
`OpenStack <https://www.openstack.org/>`__, the leading open cloud platform.
We have two options when installing OpenStack. #. **By individual charm**. This method provides a solid understanding of how
Juju works and of how OpenStack is put together. Choose this option if you
have never installed OpenStack with Juju.
#. **By charm bundle**. This method provides an automated means to install
OpenStack. Choose this option if you are familiar with how OpenStack is
built with Juju.
1. Install and configure each OpenStack component separately. Adding Ceph, The current page is devoted to method #1. See :doc:`Deploying OpenStack from a
Compute, Swift, RabbitMQ, Keystone and Neutron in this way allows you to see bundle <install-openstack-bundle>` for method #2.
exactly what Juju and MAAS are doing, and consequently, gives you a better
understanding of the underlying OpenStack deployment.
2. Use a `bundle <https://jujucharms.com/docs/stable/charms-bundles>`__ to
deploy OpenStack with a single command. A bundle is an encapsulation of a
working deployment, including all configuration, resources and references. It
allows you to effortlessly recreate a deployment with a single command or
share that deployment with other Juju users.
If this is your first foray into MAAS, Juju and OpenStack territory, we'd
recommend starting with the first option. This will give you a stronger
foundation for maintaining and expanding the default deployment. Our
instructions for this option continue below.
Alternatively, jump to :doc:`Deploying OpenStack from a
bundle <install-openstack-bundle>` to learn about deploying as a
bundle.
.. important:: .. important::
@ -42,551 +31,537 @@ bundle.
series (e.g. 'xenial' or 'bionic', but not a mix of the two). See `Series series (e.g. 'xenial' or 'bionic', but not a mix of the two). See `Series
upgrade`_ for details. upgrade`_ for details.
Deploy the Juju controller Despite the length of this page, only three distinct Juju commands will be
-------------------------- employed: :command:`juju deploy`, :command:`juju add-unit`, and :command:`juju
add-relation`. You may want to review these pertinent sections of the Juju
documentation before continuing:
:doc:`Previously <install-juju>`, we tested our MAAS and Juju configuration * `Deploying applications`_
by deploying a new Juju controller called ``maas-controller``. You can check * `Deploying to specific machines`_
this controller is still operational by typing ``juju status``. With the Juju * `Managing relations`_
controller running, the output will look similar to the following:
.. code:: bash .. TODO
Cloud topology section goes here (modelled on openstack-base README)
Model Controller Cloud/Region Version Installation progress
default maas-controller-two mymaas 2.2.1 ---------------------
App Version Status Scale Charm Store Rev OS Notes There are many moving parts involved in a charmed OpenStack install. During
much of the process there will be components that have not yet been satisfied,
which will cause error-like messages to be displayed in the output of the
:command:`juju status` command. Do not be alarmed. Indeed, these are
opportunities to learn about the interdependencies of the various pieces of
software. Messages such as **Missing relation** and **blocked** will vanish
once the appropriate applications and relations have been added and processed.
Unit Workload Agent Machine Public address Ports Message .. tip::
Machine State DNS Inst id Series AZ One convenient way to monitor the installation progress is to have command
:command:`watch -n 5 -c juju status --color` running in a separate terminal.
If you need to remove and redeploy the controller, use the following two
commands:
.. code:: bash
juju kill-controller maas-controller
juju bootstrap --constraints tags=juju mymaas maas-controller
During the bootstrap process, Juju will create a model called ``default``, as
shown in the output from ``juju status`` above.
`Models <https://jujucharms.com/docs/stable/models>`__ act as containers for
applications, and Juju's default model is great for experimentation.
We're going to create a new model called ``uos`` to hold our OpenStack
deployment exclusively, making the entire deployment easier to manage and
maintain.
To create a model called ``uos`` (and switch to it), simply type the following:
.. code:: bash
juju add-model uos
Deploy OpenStack Deploy OpenStack
---------------- ----------------
We're now going to step through adding each of the various OpenStack components Assuming you have precisely followed the instructions on the :doc:`Install Juju
to the new model. Each application will be installed from the `Charm <install-juju>` page, you should now have a Juju controller called
store <https://jujucharms.com>`__. We'll be providing the configuration for many 'maas-controller' and an empty Juju model called 'openstack'. Change to that
of the charms as a ``yaml`` file which we include as we deploy them. context now:
`Ceph OSD <https://jujucharms.com/ceph-osd>`__ .. code-block:: none
~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~
We're starting with the Ceph object storage daemon and we want to configure juju switch maas-controller:openstack
Ceph to use the second drive of a cloud node, ``/dev/sdb``. Change this to
match your own configuration if the device name on your system is different.
The configuration is held in the file called ``ceph-osd.yaml``:
.. code:: yaml In the following sections, the various OpenStack components will be added to
the 'openstack' model. Each application will be installed from the online
ceph-osd: `Charm store`_ and each will typically have configuration options specified via
osd-devices: /dev/sdb its own YAML file.
We're going to deploy Ceph-OSD to each of the four cloud nodes we've already
tagged with ``compute``. The following command will import the settings above
and deploy Ceph-OSD to each of the four nodes:
.. code:: bash
juju deploy --constraints tags=compute --config ceph-osd.yaml -n 4 ceph-osd
.. note:: .. note::
If a message from a ceph-osd unit like "Non-pristine devices detected" You do not need to wait for a Juju command to complete before issuing
appears in the output of :command:`juju status` you will need to use actions further ones. However, it can be very instructive to see the effect one
``zap-disk`` and ``add-disk`` that come with the 'ceph-osd' charm if you do command has on the current state of the cloud.
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 Ceph OSD
and installing Ubuntu. Juju then takes over and installs the necessary packages ~~~~~~~~
for the required application.
Remember, you can check on the status of a deployment using the ``juju status`` The ceph-osd application is deployed to four nodes with the `ceph-osd`_ charm.
command. To see the status of a single charm of application, append the charm The name of the block devices backing the OSDs is dependent upon the hardware
name: on the nodes. Here, we'll be using the same second drive on each cloud node:
``/dev/sdb``. File ``ceph-osd.yaml`` contains the configuration. If your
devices are not identical across the nodes you will need separate files (or
stipulate them on the command line):
.. code:: bash .. code-block:: yaml
juju status ceph-osd ceph-osd:
osd-devices: /dev/sdb
In this early stage of deployment, the output will look similar to the To deploy the application we'll make use of the 'compute' tag we placed on each
following: of these nodes on the :doc:`Install MAAS <install-maas>` page.
.. code:: bash .. code-block:: none
Model Controller Cloud/Region Version juju deploy --constraints tags=compute --config ceph-osd.yaml -n 4 ceph-osd
uoa maas-controller mymaas 2.2-beta1
App Version Status Scale Charm Store Rev OS Notes If a message from a ceph-osd unit like "Non-pristine devices detected" appears
ceph-osd 10.2.6 blocked 4 ceph-osd jujucharms 241 ubuntu 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. The
Unit Workload Agent Machine Public address Ports Message ``zap-disk`` action is destructive in nature. Only use it if you want to purge
ceph-osd/0 blocked idle 0 192.168.100.113 Missing relation: monitor the disk of all data and signatures for use by Ceph.
ceph-osd/1* blocked idle 1 192.168.100.114 Missing relation: monitor
ceph-osd/2 blocked idle 2 192.168.100.115 Missing relation: monitor
ceph-osd/3 blocked idle 3 192.168.100.112 Missing relation: monitor
Machine State DNS Inst id Series AZ Message
0 started 192.168.100.113 fr36gt xenial default Deployed
1 started 192.168.100.114 nnpab4 xenial default Deployed
2 started 192.168.100.115 a83gcy xenial default Deployed
3 started 192.168.100.112 7gan3t xenial default Deployed
Don't worry about the 'Missing relation' messages. We'll add the required
relations in a later step. You also don't have to wait for a deployment to
finish before adding further applications to Juju. Errors will resolve
themselves as applications are deployed and dependencies are met.
`Nova Compute <https://jujucharms.com/nova-compute/>`__
~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~
We're going use three machines to host the OpenStack Nova Compute application.
The first will use the following configuration file, ``compute.yaml``, while
we'll use the second and third to scale-out the same application to two other
machines.
.. code:: yaml
nova-compute:
enable-live-migration: True
enable-resize: True
migration-auth-type: ssh
virt-type: qemu
Type the following to deploy ``nova-compute`` to machine number 1:
.. code:: bash
juju deploy --to 1 --config compute.yaml nova-compute
And use the following commands to scale-out Nova Compute to machines 2 and 3:
.. code:: bash
juju add-unit --to 2 nova-compute
juju add-unit --to 3 nova-compute
As before, it's worth checking ``juju status nova-compute`` output to make sure
``nova-compute`` has been deployed to three machines. Look for lines similar to
these:
.. code:: bash
Machine State DNS Inst id Series AZ Message
1 started 192.168.100.117 7gan3t xenial default Deployed
2 started 192.168.100.118 fr36gt xenial default Deployed
3 started 192.168.100.119 nnpab4 xenial default Deployed
.. note:: .. note::
The ``nova-compute`` charm is designed to support one image format type per Since ceph-osd was deployed on four nodes and there are only four nodes
application at any one time. Changing format (see charm option available in this environment, the usage of the 'compute' tag is not
strictly necessary.
Nova compute
~~~~~~~~~~~~
The nova-compute application is deployed to one node with the `nova-compute`_
charm. We'll then scale-out the application to two other machines. File
``compute.yaml`` contains the configuration:
.. code-block:: yaml
nova-compute:
enable-live-migration: true
enable-resize: true
migration-auth-type: ssh
The initial node must be targeted by machine since there are no more free Juju
machines (MAAS nodes) available. This means we're placing multiple services on
our nodes. We've chosen machine 1:
.. code-block:: none
juju deploy --to 1 --config compute.yaml nova-compute
Now scale-out to machines 2 and 3:
.. code-block:: none
juju add-unit --to 2 nova-compute
juju add-unit --to 3 nova-compute
.. note::
The 'nova-compute' charm is designed to support one image format type per
application at any given time. Changing format (see charm option
``libvirt-image-backend``) while existing instances are using the prior ``libvirt-image-backend``) while existing instances are using the prior
format will require manual image conversion for each instance. See bug `LP format will require manual image conversion for each instance. See bug `LP
#1826888`_. #1826888`_.
`Swift storage <https://jujucharms.com/swift-storage/>`__ Swift storage
~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~ ~~~~~~~~~~~~~
The Swift-storage application is going to be deployed to the first machine The swift-storage application is deployed to one node (machine 0) with the
(``machine 0``), and scaled across the other three with the following `swift-storage`_ charm and then scaled-out to three other machines. File
configuration file: ``swift-storage.yaml`` contains the configuration:
.. code:: yaml .. code-block:: yaml
swift-storage: swift-storage:
block-device: sdc block-device: sdc
overwrite: "true" overwrite: "true"
This example configuration points to block device /dev/sdc. Adjust according to This configuration points to block device ``/dev/sdc``. Adjust according to
your available hardware. In a production environment, avoid using a loopback your available hardware. In a production environment, avoid using a loopback
device. device.
Here are the four deploy commands for the four machines: Here are the four deploy commands for the four machines:
.. code:: bash .. code-block:: none
juju deploy --to 0 --config swift-storage.yaml swift-storage juju deploy --to 0 --config swift-storage.yaml swift-storage
juju add-unit --to 1 swift-storage juju add-unit --to 1 swift-storage
juju add-unit --to 2 swift-storage juju add-unit --to 2 swift-storage
juju add-unit --to 3 swift-storage juju add-unit --to 3 swift-storage
`Neutron networking <https://jujucharms.com/neutron-api/>`__ Neutron networking
~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~ ~~~~~~~~~~~~~~~~~~
Next comes Neutron for OpenStack networking. We have just a couple of Neutron networking is implemented with three applications:
configuration options than need to be placed within ``neutron.yaml`` and we're
going to use this for two applications, ``neutron-gateway`` and ``neutron-api``:
.. code:: yaml * neutron-gateway
* neutron-api
* neutron-openvswitch
neutron-gateway: File ``neutron.yaml`` contains the configuration for two of them:
data-port: br-ex:eth1
bridge-mappings: physnet1:br-ex
neutron-api:
neutron-security-groups: True
flat-network-providers: physnet1
The ``data-port`` refers to a network interface that Neutron Gateway will bind .. code-block:: yaml
to. In the above example it is ``eth1`` and it should be an unused interface.
In the MAAS web UI this interface must be given an *IP mode* of 'Unconfigured'
(see `MAAS documentation <https://maas.io/docs/commission-nodes#heading--post-commission-configuration>`__
for guidance). Set all four nodes in this way to ensure that any node is able
to accommodate Neutron.
Deploy neutron-gateway on machine 0 now: neutron-gateway:
data-port: br-ex:eth1
bridge-mappings: physnet1:br-ex
neutron-api:
neutron-security-groups: true
flat-network-providers: physnet1
.. code:: bash The ``data-port`` setting refers to a network interface that Neutron Gateway
will bind to. In the above example it is 'eth1' and it should be an unused
interface. In MAAS this interface must be given an *IP mode* of 'Unconfigured'
(see `Post-commission configuration`_ in the MAAS documentation). Set all four
nodes in this way to ensure that any node is able to accommodate Neutron
Gateway.
juju deploy --to 0 --config neutron.yaml neutron-gateway The ``flat-network-providers`` setting enables the Neutron flat network
provider used in this example scenario and gives it the name of 'physnet1'. The
flat network provider and its name will be referenced when we create the
external public network on the :doc:`Configure OpenStack <config-openstack>`
page.
We're going to colocate the Neutron API on machine 1 by using an The ``bridge-mappings`` setting maps the data-port interface to the flat
`LXD <https://www.ubuntu.com/containers/lxd>`__ container. This is a great network provider.
solution for both local deployment and for managing cloud instances.
We'll also deploy Neutron OpenvSwitch: The neutron-gateway application will be deployed directly on machine 0:
.. code:: bash .. code-block:: none
juju deploy --to lxd:1 --config neutron.yaml neutron-api juju deploy --to 0 --config neutron.yaml neutron-gateway
juju deploy neutron-openvswitch
We've got to a stage where we can start to connect applications together. Juju's The neutron-api application will be deployed as a container on machine 1:
ability to add these links, known as a relation in Juju, is one of its best
features.
See `Managing .. code-block:: none
relationships <https://jujucharms.com/docs/stable/charms-relations>`__ in the
Juju documentation for more information on relations.
Add the network relations with the following commands: juju deploy --to lxd:1 --config neutron.yaml neutron-api
.. code:: bash The neutron-openvswitch application will be deployed by means of a subordinate
charm (it will be installed on a machine once its relation is added):
juju add-relation neutron-api neutron-gateway .. code-block:: none
juju add-relation neutron-api neutron-openvswitch
juju add-relation neutron-openvswitch nova-compute
There are still 'Missing relations' messages in the status output, leading to juju deploy neutron-openvswitch
the status of some applications to be ``blocked``. This is because there are
many more relations to be added but they'll resolve themselves automatically as
we add them.
`Percona cluster <https://jujucharms.com/percona-cluster/>`__ Three relations need to be added:
~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~
The Percona XtraDB cluster application comes next, and like Neutron API above, .. code-block:: none
we're going to use LXD.
The following ``mysql.yaml`` is the only configuration we need: juju add-relation neutron-api:neutron-plugin-api neutron-gateway:neutron-plugin-api
juju add-relation neutron-api:neutron-plugin-api neutron-openvswitch:neutron-plugin-api
juju add-relation neutron-openvswitch:neutron-plugin nova-compute:neutron-plugin
.. code:: yaml Percona cluster
~~~~~~~~~~~~~~~
mysql: The Percona XtraDB cluster is the OpenStack database of choice. The
max-connections: 20000 percona-cluster application is deployed as a single LXD container on machine 0
with the `percona-cluster`_ charm. File ``mysql.yaml`` contains the
configuration:
To deploy Percona alongside MySQL: .. code-block:: yaml
.. code:: bash mysql:
max-connections: 20000
juju deploy --to lxd:0 --config mysql.yaml percona-cluster mysql To deploy Percona while giving it an application name of 'mysql':
And there's just a single new relation to add: .. code-block:: none
.. code:: bash juju deploy --to lxd:0 --config mysql.yaml percona-cluster mysql
juju add-relation neutron-api mysql Only a single relation is needed:
`Keystone <https://jujucharms.com/keystone/>`__ .. code-block:: none
~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~
As Keystone handles OpenStack identity management and access, we're going to use juju add-relation neutron-api:shared-db mysql:shared-db
the following contents of ``keystone.yaml`` to set an admin password for
OpenStack:
.. code:: yaml Keystone
~~~~~~~~
keystone: The keystone application is deployed as a single LXD container on machine 3
admin-password: openstack with the `keystone`_ charm. No additional configuration is required. To deploy:
We'll use an LXD container on machine 3 to help balance the load a little. To .. code-block:: none
deploy the application, use the following command:
.. code:: bash juju deploy --to lxd:3 --config keystone.yaml keystone
juju deploy --to lxd:3 --config keystone.yaml keystone Then add these two relations:
Then add these relations: .. code-block:: none
.. code:: bash juju add-relation keystone:shared-db mysql:shared-db
juju add-relation keystone:identity-service neutron-api:identity-service
juju add-relation keystone mysql RabbitMQ
juju add-relation neutron-api keystone ~~~~~~~~
`RabbitMQ <https://jujucharms.com/rabbitmq-server/>`__ The rabbitmq-server application is deployed as a single LXD container on
~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~ machine 0 with the `rabbitmq-server`_ charm. No additional configuration is
required. To deploy:
We're using RabbitMQ as the messaging server. Deployment requires no further .. code-block:: none
configuration than running the following command:
.. code:: bash juju deploy --to lxd:0 rabbitmq-server
juju deploy --to lxd:0 rabbitmq-server Four relations are needed:
This brings along four new connections that need to be made: .. code-block:: none
.. code:: bash juju add-relation rabbitmq-server:amqp neutron-api:amqp
juju add-relation rabbitmq-server:amqp neutron-openvswitch:amqp
juju add-relation rabbitmq-server:amqp nova-compute:amqp
juju add-relation rabbitmq-server:amqp neutron-gateway:amqp
juju add-relation neutron-api rabbitmq-server Nova cloud controller
juju add-relation neutron-openvswitch rabbitmq-server ~~~~~~~~~~~~~~~~~~~~~
juju add-relation nova-compute:amqp rabbitmq-server
juju add-relation neutron-gateway:amqp rabbitmq-server:amqp
`Nova Cloud Controller <https://jujucharms.com/nova-cloud-controller/>`__ The nova-cloud-controller application, which includes nova-scheduler, nova-api,
~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~ and nova-conductor services, is deployed as a single LXD container on machine 2
with the `nova-cloud-controller`_ charm. File ``controller.yaml`` contains the
configuration:
This is the controller service for OpenStack, and includes the nova-scheduler, .. code-block:: yaml
nova-api and nova-conductor services.
The following simple ``controller.yaml`` configuration file will be used: nova-cloud-controller:
network-manager: Neutron
.. code:: yaml To deploy:
nova-cloud-controller: .. code-block:: none
network-manager: "Neutron"
To add the controller to your deployment, enter the following: juju deploy --to lxd:2 --config controller.yaml nova-cloud-controller
.. code:: bash Relations need to be added for six applications:
juju deploy --to lxd:2 --config controller.yaml nova-cloud-controller .. code-block:: none
Followed by these ``add-relation`` connections: juju add-relation nova-cloud-controller:shared-db mysql:shared-db
juju add-relation nova-cloud-controller:identity-service keystone:identity-service
juju add-relation nova-cloud-controller:amqp rabbitmq-server:amqp
juju add-relation nova-cloud-controller:quantum-network-service neutron-gateway:quantum-network-service
juju add-relation nova-cloud-controller:neutron-api neutron-api:neutron-api
juju add-relation nova-cloud-controller:cloud-compute nova-compute:cloud-compute
.. code:: bash OpenStack dashboard
~~~~~~~~~~~~~~~~~~~
juju add-relation nova-cloud-controller:shared-db mysql:shared-db The openstack-dashboard application (Horizon) is deployed as a single LXD
juju add-relation nova-cloud-controller keystone container on machine 3 with the `openstack-dashboard`_ charm. No additional
juju add-relation nova-cloud-controller:amqp rabbitmq-server:amqp configuration is needed. To deploy:
juju add-relation nova-cloud-controller neutron-gateway
juju add-relation neutron-api nova-cloud-controller
juju add-relation nova-compute nova-cloud-controller
`OpenStack Dashboard <https://jujucharms.com/openstack-dashboard/>`__ .. code-block:: none
~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~
We'll deploy the dashboard to another LXD container with a single command: juju deploy --to lxd:3 openstack-dashboard
.. code:: bash A single relation is required:
juju deploy --to lxd:3 openstack-dashboard .. code-block:: none
And a single relation: juju add-relation openstack-dashboard:identity-service keystone:identity-service
.. code:: bash Glance
~~~~~~
juju add-relation openstack-dashboard:identity-service keystone:identity-service The glance application is deployed as a single container on machine 2 with the
`glance`_ charm. No additional configuration is required. To deploy:
`Glance <https://jujucharms.com/glance/>`__ .. code-block:: none
~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~
For the Glance image service, deploy as follows: juju deploy --to lxd:2 glance
.. code:: bash Five relations are needed:
juju deploy --to lxd:2 glance .. code-block:: none
Relations: juju add-relation glance:image-service nova-cloud-controller:image-service
juju add-relation glance:image-service nova-compute:image-service
juju add-relation glance:shared-db mysql:shared-db
juju add-relation glance:identity-service keystone:identity-service
juju add-relation glance:amqp rabbitmq-server:amqp
.. code:: bash Ceph monitor
~~~~~~~~~~~~
juju add-relation nova-cloud-controller glance The ceph-mon application is deployed as a container on machines 1, 2, and 3
juju add-relation nova-compute glance with the `ceph-mon`_ charm. No additional configuration is required. To deploy:
juju add-relation glance mysql
juju add-relation glance keystone
juju add-relation glance rabbitmq-server
`Ceph monitor <https://jujucharms.com/ceph-mon/>`__ .. code-block:: none
~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~
For Ceph monitors (which monitor the topology of the Ceph deployment and juju deploy --to lxd:1 ceph-mon
manage the CRUSH map which is used by clients to read and write data) no juju add-unit --to lxd:2 ceph-mon
additional configuration over the defaults provided is required, so juju add-unit --to lxd:3 ceph-mon
deploy three units with this:
.. code:: bash Three relations are needed:
juju deploy --to lxd:1 ceph-mon .. code-block:: none
juju add-unit --to lxd:2 ceph-mon
juju add-unit --to lxd:3 ceph-mon
With these additional relations: juju add-relation ceph-mon:osd ceph-osd:mon
juju add-relation ceph-mon:client nova-compute:ceph
juju add-relation ceph-mon:client glance:ceph
.. code:: bash The last relation makes Ceph to be the backend for Glance.
juju add-relation ceph-osd ceph-mon Cinder
juju add-relation nova-compute ceph-mon ~~~~~~
juju add-relation glance ceph-mon
`Cinder <https://jujucharms.com/cinder/>`__ The cinder application is deployed to a container on machine 1 with the
~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~ `cinder`_ charm. File ``cinder.yaml`` contains the configuration:
For Cinder block storage, use the following ``cinder.yaml`` file: .. code-block:: yaml
.. code:: yaml cinder:
glance-api-version: 2
block-device: None
cinder: To deploy:
glance-api-version: 2
block-device: None
And deploy with this: .. code-block:: none
.. code:: bash juju deploy --to lxd:1 --config cinder.yaml cinder
juju deploy --to lxd:1 --config cinder.yaml cinder Relations need to be added for five applications:
Relations: .. code-block:: none
.. code:: bash juju add-relation cinder:cinder-volume-service nova-cloud-controller:cinder-volume-service
juju add-relation cinder:shared-db mysql:shared-db
juju add-relation cinder:identity-service keystone:identity-service
juju add-relation cinder:amqp rabbitmq-server:amqp
juju add-relation cinder:image-service glance:image-service
juju add-relation nova-cloud-controller cinder In addition, like Glance, Cinder will use Ceph as its backend. This will be
juju add-relation cinder mysql implemented via the `cinder-ceph`_ subordinate charm:
juju add-relation cinder keystone
juju add-relation cinder rabbitmq-server
juju add-relation cinder:image-service glance:image-service
juju add-relation cinder ceph-mon
`Swift proxy <https://jujucharms.com/swift-proxy/>`__ .. code-block:: none
~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~
Swift also needs a unique identifier, best generated with the ``uuid`` command. juju deploy cinder-ceph
The ``uuid`` command on Ubuntu is in the ``uuid`` package (``sudo apt-get A relation is needed for both Cinder and Ceph:
install uuid``) and it is best to produce a version 4 uuid, which is based on
random numbers, rather than a version 1 which is based on the MAC address of a
network card and a timer.
Generate the uuid by running: .. code-block:: none
.. code:: bash juju add-relation cinder-ceph:storage-backend cinder:storage-backend
juju add-relation cinder-ceph:ceph ceph-mon:client
uuid -v 4 Swift proxy
~~~~~~~~~~~
The output UUID is used for the ``swift-hash`` value in the The swift-proxy application is deployed to a container on machine 0 with the
``swift-proxy.yaml`` configuration file: `swift-proxy`_ charm. File ``swift-proxy.yaml`` contains the configuration:
.. code:: yaml .. code-block:: yaml
swift-proxy: swift-proxy:
zone-assignment: auto zone-assignment: auto
swift-hash: "a1ee9afe-194c-11e7-bf0f-53d662bc4339" swift-hash: "<uuid>"
Use the following command to deploy: Swift proxy needs to be supplied with a unique identifier (UUID). Generate one
with the :command:`uuid -v 4` command (you may need to first install the
``uuid`` deb package) and insert it into the file.
.. code:: bash To deploy:
juju deploy --to lxd:0 --config swift-proxy.yaml swift-proxy .. code-block:: none
These are its two relations: juju deploy --to lxd:0 --config swift-proxy.yaml swift-proxy
.. code:: bash Two relations are needed:
juju add-relation swift-proxy swift-storage .. code-block:: none
juju add-relation swift-proxy keystone
`NTP <https://jujucharms.com/ntp/>`__ juju add-relation swift-proxy:swift-storage swift-storage:swift-storage
~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~ juju add-relation swift-proxy:identity-service keystone:identity-service
The final component we need to deploy is a Network Time Protocol client, to keep NTP
everything in time. This is added with the following simple command: ~~~
.. code:: bash The final component needed is an NTP client to keep everything synchronised.
This is done with the `ntp`_ subordinate charm:
juju deploy ntp .. code-block:: none
This last ``add-relation`` command finishes all the connections we need to juju deploy ntp
make. It will add an ntp unit alongside each of the four ceph-osd units:
.. code:: bash This single relation will add an ntp unit alongside each of the four ceph-osd
units:
juju add-relation ceph-osd ntp .. code-block:: none
All that's now left to do is wait on the output from ``juju status`` to show juju add-relation ceph-osd:juju-info ntp:juju-info
when everything is ready (everything turns green, if your terminal support
colour).
.. _test_openstack: .. _test_openstack:
Test OpenStack Final results and dashboard access
-------------- ----------------------------------
After everything has deployed and the output of ``juju status`` settles, you can Once all the applications have been deployed and the relations between them
check to make sure OpenStack is working by logging into the Horizon dashboard. have been added we need to wait for the output of :command:`juju status` to
settle. The final results should be devoid of any error-like messages. If your
terminal supports colours then you should see only green (not amber nor red) .
Example (monochrome) output for a successful cloud deployment is given
:ref:`here <install_openstack_juju_status>`.
The quickest way to get the IP address for the dashboard is with the following One milestone in the deployment of OpenStack is the first login to the Horizon
command: dashboard. You will need its IP address and the admin password.
.. code:: bash Obtain the address in this way:
juju status --format=yaml openstack-dashboard | grep public-address | awk '{print $2}' .. code-block:: none
juju status --format=yaml openstack-dashboard | grep public-address | awk '{print $2}'
The password is queried from Keystone:
.. code-block:: none
juju run --unit keystone/0 leader-get admin_passwd
In this example, the address is '10.0.0.14' and the password is
'kohy6shoh3diWav5'.
The dashboard URL then becomes: The dashboard URL then becomes:
``http://<ip-address>/horizon`` **http://10.0.0.14/horizon**
On the resulting web page you will be able to log in with these default And the credentials are:
credentials:
* Domain: **admin_domain** | Domain: **admin_domain**
* User Name: **admin** | User Name: **admin**
* Password: **openstack** | Password: **kohy6shoh3diWav5**
|
You should then see something similar to the following: Once logged in you should see something like this:
.. figure:: ./media/install-openstack_horizon-2.png .. figure:: ./media/install-openstack_horizon.png
:alt: Horizon dashboard :alt: Horizon dashboard
Next steps Next steps
---------- ----------
Congratulations, you've successfully deployed a working OpenStack environment You have successfully deployed OpenStack using both Juju and MAAS. The next
using both Juju and MAAS. The next step is to :doc:`configure step is to render the cloud functional for users. This will involve setting up
OpenStack <config-openstack>` for use within a production environment. networks, images, and a user environment.
.. raw:: html
<!-- LINKS -->
.. LINKS
.. _OpenStack Charms: https://docs.openstack.org/charm-guide/latest/openstack-charms.html .. _OpenStack Charms: https://docs.openstack.org/charm-guide/latest/openstack-charms.html
.. _Charm upgrades: app-upgrade-openstack#charm-upgrades .. _Charm upgrades: app-upgrade-openstack#charm-upgrades
.. _Series upgrade: app-series-upgrade .. _Series upgrade: app-series-upgrade
.. _Charm store: https://jaas.ai/store
.. _Post-commission configuration: https://maas.io/docs/commission-nodes#heading--post-commission-configuration
.. _Deploying applications: https://jaas.ai/docs/deploying-applications
.. _Deploying to specific machines: https://jaas.ai/docs/deploying-advanced-applications#heading--deploying-to-specific-machines
.. _Managing relations: https://jaas.ai/docs/relations
.. raw:: html .. CHARMS
.. _ceph-mon: https://jaas.ai/ceph-mon
<!-- IMAGES --> .. _ceph-osd: https://jaas.ai/ceph-osd
.. _cinder: https://jaas.ai/cinder
.. _cinder-ceph: https://jaas.ai/cinder-ceph
.. _glance: https://jaas.ai/glance
.. _keystone: https://jaas.ai/keystone
.. _neutron-gateway: https://jaas.ai/neutron-gateway
.. _neutron-api: https://jaas.ai/neutron-api
.. _neutron-openvswitch: https://jaas.ai/neutron-openvswitch
.. _nova-cloud-controller: https://jaas.ai/nova-cloud-controller
.. _nova-compute: https://jaas.ai/nova-compute
.. _ntp: https://jaas.ai/ntp
.. _openstack-dashboard: https://jaas.ai/openstack-dashboard
.. _percona-cluster: https://jaas.ai/percona-cluster
.. _rabbitmq-server: https://jaas.ai/rabbitmq-server
.. _swift-proxy: https://jaas.ai/swift-proxy
.. _swift-storage: https://jaas.ai/swift-storage
.. BUGS .. BUGS
.. _LP #1826888: https://bugs.launchpad.net/charm-deployment-guide/+bug/1826888 .. _LP #1826888: https://bugs.launchpad.net/charm-deployment-guide/+bug/1826888

BIN
deploy-guide/source/media/install-openstack_horizon-2.png
View File

Binary file not shown.
Side by Side

Before

Width:  |  Height:  |  Size: 745 KiB

BIN
deploy-guide/source/media/install-openstack_horizon.png
View File

Binary file not shown.
Side by Side Swipe Overlay

Before

Width:  |  Height:  |  Size: 46 KiB

After

Width:  |  Height:  |  Size: 745 KiB