fdd62f8fbf
In the current implementation, the charm instance i.e., DesignateCharm<*> passes a release name based on python-keystonemiddleware package. However the internal logic ignores the package and installs openstack-release package and determines the release and creates singleton class for that release. The singelton class determines the list of packages etc. However at this point of time, the cloud-archive source is not yet updated. In case of jammy-caracal deployment, the openstack-release package is installed from jammy since the cloud archive source is not updated and hence openstack release is considered as yoga. This means packages listed in DesignateCharmYoga will be installed that includes designate-agent. After running some handlers, configure_designate_full crosschecks the packages with openstack-origin configuration and starts upgrading the packages to caracal. There are no purge_packages listed in CharmDesignateCaracal and so designate-agent is not removed during this upgrade. Do not pass any release so that charms.openstack library figures out the release name after updating the cloud-archive sources. This should fix issues for a greenfield deployment. For the case of upgrades from earlier releases where designate-agent is already installed, update purge packages in CharmDesignateCaracal. To remove/purge nrpe service check, add logic to trigger remove_deperecated_packages. There is a case where designate-agent gets purged and reinstalled due to the way hooks are triggered and singleton class is maintained. To overcome this, always remove_obselete_packages in configure_designate_full handler. Closes-Bug: #2111227 Change-Id: I9f8ce93b9751a65e8e181cf9aa7411a4047318bb
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.