Using OpenStack with Juju
Although Juju doesn’t have baked-in knowledge of your OpenStack cloud, it does know how such clouds work in general. We just need to provide some information to add it to the list of known clouds.
Adding an OpenStack Cloud
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.
This command recognises the below variables. Any values found will show up as default values when the interactive mode is used. For clarity, the corresponding prompts are given in parentheses:
OS_AUTH_URL(cloud API endpoint URL)
OS_CACERT(path to the CA certificate file)
These are typically defined in a file called
novarc. Have your shell source it (e.g.
source novarc) prior to invoking
For the manual method of adding an OpenStack cloud, see below section Manually adding an OpenStack cloud.
To interactively add a cloud definition to the local client cache (just
add-cloud on versions prior to
juju add-cloud --local
Example user session:
Cloud Types lxd maas manual openstack vsphere 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 access-key userpass 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`).
Note that it is possible to choose more than one authorisation method - just separate the values with commas.
Confirm the addition of the cloud with the
clouds --local command (just
clouds on versions prior to
Manually adding an OpenStack cloud
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:
clouds: mystack: type: openstack auth-types: [access-key,userpass] regions: dev1: endpoint: https://openstack.example.com:35574/v3.0/
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
add-cloud command only operates locally (there is no
Gathering credential information
The credential information is found on your private or public OpenStack account.
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:
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.
Images and private clouds
OpenStack requires access to images for its instances to use. If you have chosen to use a private OpenStack cloud you will need to ensure that images have been set up. This is covered on the Cloud image metadata page.
Creating a controller
Once the image metadata has been gathered, either locally or via a registered and running Simplestream service, check your OpenStack networks. If there are multiple possible networks available to the cloud, it is also necessary to specify the network name or UUID for Juju to use to boot instances. Both the network name and UUID can be retrieved with the following command:
openstack network list
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.
With the product-streams service running in your OpenStack Cloud, you are now ready to create a Juju controller:
juju bootstrap <cloud> <controller name> --config network=<network_id>
or if the simplestream data is local:
juju bootstrap <cloud> <controller name> --config network=<network_id> \ --metadata-source ~/simplestreams/images
or if there is an external network configured for instances that are only accessible via floating IP:
juju bootstrap <cloud> <controller name> --config network=<network_id> \ --config external-network=<external_network_id> --config use-floating-ip=true
For a detailed explanation and examples of the
bootstrap command see the Creating a controller page.
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
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: