openstack/charm-ceilometer
Code Issues Proposed changes

Apply HA section template to README

Browse Source 
Change-Id: I92e528c862742704a6fd8eeb7731cdcb9f6051d1
This commit is contained in:
Peter Matulis 2020-05-29 13:52:30 -04:00
parent 7ad2d31417
commit c35ba750a5
1 changed files with 17 additions and 36 deletions
Show Stats Download Patch File Download Diff File Expand all files Collapse all files

53
README.md
View File

@ -1,5 +1,4 @@
Overview
--------
# Overview
This charm provides the Ceilometer service for OpenStack.
@ -7,8 +6,7 @@ Ceilometer is made up of 2 separate services: an API service, and a collector
service. This charm allows them to be deployed in different combination,
depending on user preference and requirements.
Usage
-----
## Usage
In order to deploy Ceilometer service (prior to Queens), the MongoDB
service is required:
@ -59,42 +57,19 @@ amqp-listener interface for all message brokers ceilometer should monitor.
juju add-relation ceilometer:amqp-listener rabbitmq-neutron
juju add-relation ceilometer:amqp-listener rabbitmq-nova-cell2
HA/Clustering
-------------
## High availability
There are two mutually exclusive high availability options: using virtual
IP(s) or DNS. In both cases, a relationship to hacluster is required which
provides the corosync back end HA functionality.
When more than one unit is deployed with the [hacluster][hacluster-charm]
application the charm will bring up an HA active/active cluster.
To use virtual IP(s) the clustered nodes must be on the same subnet such that
the VIP is a valid IP on the subnet for one of the node's interfaces and each
node has an interface in said subnet. The VIP becomes a highly-available API
endpoint.
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.
At a minimum, the config option 'vip' must be set in order to use virtual IP
HA. If multiple networks are being used, a VIP should be provided for each
network, separated by spaces. Optionally, vip_iface or vip_cidr may be
specified.
See [OpenStack high availability][cdg-ha-apps] in the [OpenStack Charms
Deployment Guide][cdg] for details.
To use DNS high availability there are several prerequisites. However, DNS HA
does not require the clustered nodes to be on the same subnet.
Currently the DNS HA feature is only available for MAAS 2.0 or greater
environments. MAAS 2.0 requires Juju 2.0 or greater. The clustered nodes must
have static or "reserved" IP addresses registered in MAAS. The DNS hostname(s)
must be pre-registered in MAAS before use with DNS HA.
At a minimum, the config option 'dns-ha' must be set to true and at least one
of 'os-public-hostname', 'os-internal-hostname' or 'os-internal-hostname' must
be set in order to use DNS HA. One or more of the above hostnames may be set.
The charm will throw an exception in the following circumstances:
If neither 'vip' nor 'dns-ha' is set and the charm is related to hacluster
If both 'vip' and 'dns-ha' are set as they are mutually exclusive
If 'dns-ha' is set and none of the os-{admin,internal,public}-hostname(s) are
set
Network Space support
---------------------
## Network Space support
This charm supports the use of Juju Network Spaces, allowing the charm to be bound to network space configurations managed directly by Juju. This is only supported with Juju 2.0 and above.
@ -116,3 +91,9 @@ alternatively these can also be provided as part of a juju native bundle configu
NOTE: Spaces must be configured in the underlying provider prior to attempting to use them.
NOTE: Existing deployments using os-*-network configuration options will continue to function; these options are preferred over any network space binding provided if set.
<!-- LINKS -->
[hacluster-charm]: https://jaas.ai/hacluster
[cdg]: https://docs.openstack.org/project-deploy-guide/charm-deployment-guide
[cdg-ha-apps]: https://docs.openstack.org/project-deploy-guide/charm-deployment-guide/latest/app-ha.html#ha-applications