Ubuntu – How to deploy an OpenStack cloud with Juju

jujuopenstack

I'd like to get a test cloud up and running in preparation for a possible deployment of 12.04. I messed with the UEC a bit, but have had a much harder time finding anything helpful as a primer for the new stack. There is generic documentation on Diablo, but there are likely to be a lot of pieces already handy in Ubuntu that a specific guide could save time with.

Also, as much as I would love to, my budget doesn't include the $4-6k to get a small cluster running with the Canonical support.

Best Answer

Installing OpenStack

If you want to get up and running quickly go here instead:

This answer is a more detailed look at how to use Juju with OpenStack.

Scope

The OpenStack platform is powerful and its uses diverse. This section of documentation is primarily concerned with deploying a "standard" running OpenStack system using, but not limited to, Canonical components such as MAAS, Juju and Ubuntu. Where appropriate other methods and software will be mentioned.

Assumptions

  1. Use of MAAS - follow these intructions first.
  2. Use of Juju
  3. Local network configuration - This document assumes that you have an adequate local network configuration, including separate interfaces for access to the OpenStack cloud. Ideal networks are laid out in the [MAAS][MAAS documentation for OpenStack].

Planning an installation

Before deploying any services, it is very useful to take stock of the resources available and how they are to be used. OpenStack comprises of a number of interrelated services (Nova, Swift, etc) which each have differing demands in terms of hosts. For example, the Swift service, which provides object storage, has a different requirement than the Nova service, which provides compute resources.

The minimum requirements for each service and recommendations are laid out in the official OpenStack Operations Guide

The recommended composition of nodes for deploying OpenStack with MAAS and Juju is that all nodes in the system should be capable of running ANY of the services. This is best practice for the robustness of the system, as since any physical node should fail, another can be repurposed to take its place. This obviously extends to any hardware requirements such as extra network interfaces.

If for reasons of economy or otherwise you choose to use different configurations of hardware, you should note that your ability to overcome hardware failure will be reduced. It will also be necessary to target deployments to specific nodes - see the section in the MAAS documentation on tags.

Create the OpenStack configuration file

We will be using Juju charms to deploy the component parts of OpenStack. Each charm encapsulates everything required to set up a particular service. However, the individual services have many configuration options, some of which we will want to change.

To make this task easier and more reproduceable, we will create a separate configuration file with the relevant options for all the services. This is written in a standard YAML format (see www.yaml.org if this is unfamiliar to you).

Here is an example of an openstack-config.yaml:

keystone:
  admin-password: openstack
  debug: 'true'
  log-level: DEBUG
nova-cloud-controller:
  network-manager: 'Neutron'
  quantum-security-groups: 'yes'
  neutron-external-network: Public_Network
nova-compute:
  enable-live-migration: 'True'
  migration-auth-type: "none"
  virt-type: kvm
  #virt-type: lxc
  enable-resize: 'True'
quantum-gateway:
  ext-port: 'eth1'
  plugin: ovs
glance:
  ceph-osd-replication-count: 3
cinder:
  block-device: None
  ceph-osd-replication-count: 3
  overwrite: "true"
  glance-api-version: 2
ceph:
  fsid: a51ce9ea-35cd-4639-9b5e-668625d3c1d8
  monitor-secret: AQCk5+dR6NRDMRAAKUd3B8SdAD7jLJ5nbzxXXA==
  osd-devices: /dev/sdb
  osd-reformat: 'True'

For all services, we can configure the openstack-origin to point to an install source. In this case, we will rely on the default, which will point to the relevant sources for the Ubuntu 14.04 LTS Trusty release. Further configuration for each service is explained in this document.

Other configurations

Other settings and configuration options are possible for deployment of the OpenStack services. These are detailed in the documentation of the individual charms used by Juju, and can be inspected by visiting the online Juju Charm Store and searching for the charm using the search box in the top left-hand-side of the page. the configuration settings are then detailed under "Configuration" in the main page, as shown:

enter image description here

Deploying OpenStack with Juju

Now that the configuration is defined, we can use Juju to deploy and relate the services.

Initialising Juju

Juju requires a minimal amount of setup. Here we assume it has already been configured to work with your MAAS cluster (see the [Juju Install Guide][juju_install] for more information on this.

Firstly, we need to fetch images and tools that Juju will use:

juju sync-tools --debug

Then we can create the bootstrap instance:

juju bootstrap --upload-tools --debug

We use the upload-tools switch to use the local versions of the tools which we just fetched. The debug switch will give verbose output which can be useful. This process may take a few minutes, as Juju is creating an instance and installing the tools. When it has finished, you can check the status of the system with the command:

juju status

This should return something like:

environment: maas
machines:
  "0":
    agent-state: started
    agent-version: 1.18.1.1
    dns-name: localhost
    instance-id: localhost
    series: trusty

Deploy the OpenStack Charms

Now that the Juju bootstrap node is up and running we can deploy the services required to make our OpenStack installation. To configure these services properly as they are deployed, we will make use of the configuration file we defined earlier, by passing it along with the --config switch with each deploy command. Substitute in the name and path of your config file if different.

It is useful but not essential to deploy the services in the order below. It is also highly reccommended to open an additional terminal window and run the command juju debug-log. This will output the logs of all the services as they run, and can be useful for troubleshooting.

It is also recommended to run a juju status command periodically, to check that each service has been installed and is running properly. Juju will automatically try to fetch the best possible version of the charm from online Charm Store. If you are installing from within a restricted or closed network, it is possible to pre-fetch the required charms. See [the documentation for offline charms][charms-offline].

juju deploy --to=0 juju-gui
juju deploy rabbitmq-server
juju deploy mysql
juju deploy --config openstack-config.yaml openstack-dashboard
juju deploy --config openstack-config.yaml keystone
juju deploy --config openstack-config.yaml ceph -n 3 
juju deploy --config openstack-config.yaml nova-compute -n 3
juju deploy --config openstack-config.yaml quantum-gateway
juju deploy --config openstack-config.yaml cinder
juju deploy --config openstack-config.yaml nova-cloud-controller
juju deploy --config openstack-config.yaml glance
juju deploy --config openstack-config.yaml ceph-radosgw

Add relations between the OpenStack services

Although the services are now deployed, they are not yet connected together. Each service currently exists in isolation. We use the juju add-relation command to make them aware of each other and set up any relevant connections and protocols. This extra configuration is taken care of by the individual charms themselves.

We should start adding relations between charms by setting up the Keystone authorization service and its database, as this will be needed by many of the other connections:

juju add-relation keystone mysql

We wait until the relation is set. After it finishes check it with juju status:

juju status mysql
juju status keystone

It can take a few moments for this service to settle. Although it is certainly possible to continue adding relations (Juju manages a queue for pending actions) it can be counterproductive in terms of the overall time taken, as many of the relations refer to the same services.

The following relations also need to be made:

juju add-relation nova-cloud-controller mysql
juju add-relation nova-cloud-controller rabbitmq-server
juju add-relation nova-cloud-controller glance
juju add-relation nova-cloud-controller keystone
juju add-relation nova-compute mysql
juju add-relation nova-compute rabbitmq-server
juju add-relation nova-compute glance
juju add-relation nova-compute nova-cloud-controller
juju add-relation glance mysql
juju add-relation glance keystone
juju add-relation cinder keystone
juju add-relation cinder mysql
juju add-relation cinder rabbitmq-server
juju add-relation cinder nova-cloud-controller
juju add-relation openstack-dashboard keystone
juju add-relation swift-proxy swift-storage
juju add-relation swift-proxy keystone

Finally, the output of juju status should show the all the relations as complete. The OpenStack cloud is now running, but it needs to be populated with some additional components before it is ready for use.

Related Question