Overview
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.
Important: This documentation supports version 3.x of the Juju client.
See the OpenStack Charm
guide if you are using the 2.9.x client.
Usage
Configuration
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.
openstack-origin
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’).
Deployment
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 integrate placement-mysql-router:db-router mysql-innodb-cluster:db-router
juju integrate placement-mysql-router:shared-db placement:shared-db
Add relations to the remaining applications:
juju integrate placement:identity-service keystone:identity-service
juju integrate 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.
Documentation
The OpenStack Charms project maintains two documentation guides:
- OpenStack Charm Guide: for project information, including development and support notes
- OpenStack Charms Deployment Guide: for charm usage information
Bugs
Please report bugs on Launchpad.
Navigation
| Level | Path | Navlink |
|---|---|---|
| 1 | Home |