Juju Charm - Placement
You can not select more than 25 topics Topics must start with a letter or number, can include dashes ('-') and can be up to 35 characters long.
Aurelien Lourot 6535991f12 Sync release-tools 2 months ago
files Release sync for 20.08 1 year ago
lib Add wallaby package version 5 months ago
reactive Fix race in http <-> https switch 12 months ago
templates/train Let placement log to syslog 1 year ago
tests Test bundles for focal-wallaby and hirsute-wallaby 5 months ago
HACKING.md Initial Commit 2 years ago
README.md Review README 7 months ago
copyright Initial Commit 2 years ago
icon.svg Remove inherited configuration options invalid for charm 1 year ago
layer.yaml Initial Commit 2 years ago
metadata.yaml Add impish to metadata.yaml 4 months ago
test-requirements.txt Sync release-tools 2 months ago
tox.ini Sync release-tools 10 months ago
wheelhouse.txt Updates to flip all libraries back to master 5 months ago



The placement charm deploys Placement, the core OpenStack API service that tracks the inventory and usage of various cloud resources (e.g. compute, storage, network addresses). The charm works alongside other Juju-deployed OpenStack services.

Note: The placement charm is supported starting with OpenStack Train.



This section covers common and/or important configuration options. See file config.yaml for the full list of options, along with their descriptions and default values. See the Juju documentation for details on configuring applications.


The openstack-origin option states the software sources. A common value is an OpenStack UCA release (e.g. 'cloud:bionic-ussuri' or 'cloud:focal-victoria'). See Ubuntu Cloud Archive. The underlying host's existing apt sources will be used if this option is not specified (this behaviour can be explicitly chosen by using the value of 'distro').


Placement is often containerised. Here a single unit is deployed to a new container on machine '1':

juju deploy --to lxd:1 placement

Placement requires these applications to be present: keystone, nova-cloud-controller, and a cloud database.

The database application is determined by the series. Prior to focal percona-cluster is used, otherwise it is mysql-innodb-cluster. In the example deployment below mysql-innodb-cluster has been chosen.

juju deploy mysql-router placement-mysql-router
juju add-relation placement-mysql-router:db-router mysql-innodb-cluster:db-router
juju add-relation placement-mysql-router:shared-db placement:shared-db

Add relations to the remaining applications:

juju add-relation placement:identity-service keystone:identity-service
juju add-relation placement:placement nova-cloud-controller:placement

Upgrading to OpenStack Train

Prior to OpenStack Train, the placement API was managed by the nova-cloud-controller charm. Some extra steps are therefore needed when performing a Stein to Train upgrade. The documented procedure can be found on the Special charm procedures page in the OpenStack Charms Deployment Guide.

High availability

When more than one unit is deployed with the hacluster application the charm will bring up an HA active/active cluster.

There are two mutually exclusive high availability options: using virtual IP(s) or DNS. In both cases the hacluster subordinate charm is used to provide the Corosync and Pacemaker backend HA functionality.

See Infrastructure high availability in the OpenStack Charms Deployment Guide for details.


The OpenStack Charms project maintains two documentation guides:


Please report bugs on Launchpad.