History

Zuul a8152b789c Merge "separate rndc.key file per application"		2024-03-25 17:06:11 +00:00
..
files	Sync charm/ceph helpers, tox, and requirements	2019-10-01 12:57:32 -05:00
lib/charm	separate rndc.key file per application	2024-03-25 09:24:08 +00:00
reactive	separate rndc.key file per application	2024-03-25 09:24:08 +00:00
templates	separate rndc.key file per application	2024-03-25 09:24:08 +00:00
tests	Updates for caracal testing support	2024-02-12 18:19:24 +00:00
README.md	Streamline README for policy overrides	2020-01-09 12:11:34 -05:00
config.yaml	Add 2023.2 Bobcat support	2023-08-03 13:57:55 -04:00
icon.svg	Update charm icon	2017-08-02 18:36:38 +01:00
layer.yaml	Add NRPE checks for services	2021-08-26 11:18:24 +02:00
metadata.yaml	Updates for caracal testing support	2024-02-12 18:19:24 +00:00
test-requirements.txt	Fix charm for tox4 compatibility	2023-01-17 14:56:01 +00:00
tox.ini	Updates for caracal tox.ini	2024-02-24 20:11:30 +00:00
wheelhouse.txt	Updates to flip all libraries back to master	2021-05-03 16:04:20 +01:00

README.md

Overview

This charm provides Designate (DNSaaS) for an OpenStack Cloud.

Usage

Designate relies on services from the mysql, rabbitmq-server and keystone charms:

juju deploy designate
juju deploy mysql
juju deploy rabbitmq-server
juju deploy keystone
juju deploy memcached
juju add-relation designate memcached
juju add-relation designate mysql
juju add-relation designate rabbitmq-server
juju add-relation designate keystone

To add support for DNS record auto-generation when Neutron ports and floating IPs are created the charm needs a relation with neutron-api charm:

juju deploy neutron-api
juju add-relation designate neutron-api

The charm needs to store DNS records. This can be achieved by setting the dns-slave config option or by relating to the designate-bind charm:

juju deploy designate-bind
juju add-relation designate designate-bind

For Queens and later, the nameservers config value must be set:

juju config designate nameservers="ns1.example.com. ns2.example.com."

Policy Overrides

Policy overrides is an advanced feature that allows an operator to override the default policy of an OpenStack service. The policies that the service supports, the defaults it implements in its code, and the defaults that a charm may include should all be clearly understood before proceeding.

Caution: It is possible to break the system (for tenants and other services) if policies are incorrectly applied to the service.

Policy statements are placed in a YAML file. This file (or files) is then (ZIP) compressed into a single file and used as an application resource. The override is then enabled via a Boolean charm option.

Here are the essential commands (filenames are arbitrary):

zip overrides.zip override-file.yaml
juju attach-resource designate policyd-override=overrides.zip
juju config designate use-policyd-override=true

See appendix Policy Overrides in the OpenStack Charms Deployment Guide for a thorough treatment of this feature.

Bugs

Please report bugs on Launchpad.

For general charm questions refer to the OpenStack Charm Guide.