Using OpenStack with Juju

Working with your OpenStack cloud is easy.

  • Provide Juju with knowledge of your OpenStack cloud, such as its IP address.
  • Add your access credentials
  • Create a controller

This page takes you those three steps. It also provides some extra information that’s specific to enabling OpenStack to work well with Juju. For example, every OpenStack cloud defines its own instance types.

Adding an OpenStack Cloud

The juju add-cloud command defines a cloud for Juju. It’s useful to have OpenStack environment variables defined running it. Assuming that you have a “novarc” file available to you, use source (or the equivalent command call on MS Windows ) to load the variables into your environment.

source /path/to/novarc

…via an interactive prompt

Use the add-cloud command to interactively add your OpenStack cloud to Juju’s list of clouds. You will need to supply a name you wish to call your cloud and the unique API endpoint, the authentication type(s), and region information.

juju add-cloud --local

Here is an example interactive session:

Cloud Types

Select cloud type: openstack

Enter a name for your openstack cloud: myopenstack

Enter the API endpoint url for the cloud [https://x.x.x.x:5000/v3]:

Enter the filename of the CA certificate to access OpenStack cloud (optional) [/home/ubuntu/cacert.pem]:

Auth Types

Select one or more auth types separated by commas: userpass

Enter region name: dev1

Enter the API endpoint url for the region [use cloud api url]:

Enter another region? (Y/n): n

Successfully read CA Certificate from /home/ubuntu/test_certs/cacert.pem
Cloud "myopenstack" successfully added

You will need to add credentials for this cloud (`juju add-credential myopenstack`)
before creating a controller (`juju bootstrap myopenstack`).

juju add-cloud command pre-populates the defaults with the following environment variables.

  • OS_AUTH_URL becomes the default API endpoint URL
  • OS_CACERT becomes the default path to the CA certificate file
  • OS_REGION_NAME becomes the default refion name

It is possible to choose more than one authorisation method - just separate the values with commas.

..via a cloud definition file

This section shows how to manually add an OpenStack cloud to Juju (see Adding clouds manually for background information). It also demonstrates how multiple authentication types can be allowed.

The manual method necessitates the use of a YAML-formatted configuration file. Here is an example:

      type: openstack
      auth-types: [access-key,userpass]

Adding a cloud manually can be done locally or, since v.2.6.0, remotely (on a controller). Here, we’ll show how to do it locally (client cache).

To add cloud ‘mystack’, assuming the configuration file is mystack.yaml in the current directory, we would run:

juju add-cloud --local mystack mystack.yaml

In versions prior to v.2.6.0 the add-cloud command only operates locally (there is no --local option).

Gathering credential information

The credential information is found on your private or public OpenStack account.

Adding credentials

The Credentials page offers a full treatment of credential management.

In order to access OpenStack, you will need to add credentials to Juju. This can be done in one of three ways.

Using the interactive method

Armed with the gathered information, you can add credentials with the command:

juju add-credential mystack

The command will interactively prompt you for the information needed for the chosen cloud. For the authentication type, either ‘access-key’, ‘userpass’, or ‘access-key,userpass’ (i.e. both are allowed) can be selected.

Alternately, you can use these credentials with Juju as a Service where you can deploy charms using a web GUI.

Using a file

A YAML-formatted file, say mycreds.yaml, can be used to store credential information for any cloud. This information is then added to Juju by pointing the add-credential command to the file:

juju add-credential myopenstack -f mycreds.yaml

See section Adding credentials from a file for guidance on what such a file looks like.

Using environment variables

With OpenStack you have the option of adding credentials using the following environment variables that may already be present (and set) on your client system:


Add this credential information to Juju in this way:

juju autoload-credentials

For any found credentials you will be asked which ones to use and what name to store them under.

On Linux systems, the file $HOME/.novarc may be used to define these variables and is parsed by the above command as part of the scanning process.

For background information on this method read section Adding credentials from environment variables.

Creating a controller

For many Openstack installations, you should now be in a position to create the controller. At a command line prompt, use the juju bootstrap. This provisions a instance on your OpenStack cloud and installs the Juju controller within it.

juju bootstrap <cloud> <controller-name>

This operation may fail with some installations and require more configuration. Here are some tips for two scenarios that

Images and private clouds

OpenStack requires access to images to provision instances. Configuring this correctly is covered on the Cloud image metadata page.

If your image metadata is available locally, the --metadata-source option is available to you.

juju bootstrap <cloud> <controller name> \
               --metadata-source /path/to/simplestream/images

Working with multiple networks

If there are multiple networks available, you will need to specify the intended network. Check your OpenStack networks with the openstack command:

openstack network list

Providing the preferred network’s name or Choose the network you want the instances to boot from. You can use either the network name or the UUID with the ‘network’ configuration option when bootstrapping a new controller.

juju bootstrap <cloud> <controller-name> \
               --model-default network=<network-id>

If there is an external network configured for instances that are only accessible via floating IP, add the use-floating-up configuration option:

juju bootstrap <cloud> <controller-name> \
               --model-default network=<network-id> \
               --model-default external-network=<external-network-id> \
               --model-default use-floating-ip=true

For a detailed explanation and examples of the bootstrap command see the Creating a controller page.

OpenStack-specific features

v.2.6.4 provides a new constraint: ‘root-disk-source’. Specifying the string volume tells Juju to use Cinder block storage volumes that will be used to create instances’ root disks:

juju deploy myapp --constraints root-disk-source=volume

Next steps

A controller is created with two models - the ‘controller’ model, which should be reserved for Juju’s internal operations, and a model named ‘default’, which can be used for deploying user workloads.

See these pages for ideas on what to do next:

We should tell people to do

juju bootstrap ... --model-default use-floating-ip=true

instead of

juju bootstrap ... --config use-floating-ip=true

because the latter only affects the default model, whereas the former will affect all models the user will create. See Configuring models. I personally wasted a lot of time because of this. I was creating my own model right after bootstrapping the controller and couldn’t understand why that option had no effect.

Oh wow, I feel your pain. Thanks for taking the time to comment. I’ll update the recommendation. [Edit: I’ve made several changes to the document. Hopefully it’s easier to follow now.]

1 Like

@timClicks Thanks for the quick reaction! It’s actually --model-default, not --model-defaults (or do both work?). It’s easy to mix up with juju model-defaults which takes an ‘s’ :wink:

Fixed! Thanks for taking another look :slight_smile: