By overriding the variable `designate_backend_ssl: True` HTTPS will
be enabled, disabling HTTP support on the designate backend api.
The ansible-role-pki is used to generate the required TLS
certificates if this functionality is enabled.
Depends-On: https://review.opendev.org/c/openstack/openstack-ansible/+/879085
Change-Id: Id5c18a7305c744a2b0252f62debb1b5654e4abd7
At the moment we don't restart services if systemd unit file is changed.
We knowingly prevent systemd_service role handlers to execute
by providing `state: started` as otherwise service will be restarted twice.
With that now we ensure that role handlers will also listen for systemd
unit changes.
Change-Id: I3dcb02cfd8c5057411488dfefdd0b5381231a972
Right now when designate is being installed for the first time, role
tries to run pool update before database is being populated. That
happens due to flushing handlers early as db sync requires service
to run with relevant config. This regression has been implemented
with [1].
To resolve it we move copy of pools.yaml after handlers are flushed
first time and after db sync process.
We also move service_setup before first flush as otherwise service
won't be able to start properly anyway.
There's no need to copy pools.yaml to each designate container and run
pool update multiple times - it's enough to do that once.
[1] 87eb5d46cd
Change-Id: I3b3aaf48f990e229ba5ca3ec5127780fa70228d0
Move designate-mange pool update command to handlers
since we need to run it only when pools.yaml is changed.
We also don't need to restart designate service, when pools.yaml is
updated.
Change-Id: I7f3d6bd777ce5a6e0f3372f0f6e29cb5499d5419
With changes inside Designate merged about policy-incode, there
is no longer a default policy.json file in the venv, so we
need to change how we implement the file, and should only do
so if there is a config override configured for it.
If there is no policy override configured, but a policy.json
file is present, then it's likely left over from a previous
build. To ensure that we do not carry legacy configuration
files which override the policy-in-code we remove the legacy
file. This is done on restart to ensure that the policy still
applies until the code is updated.
Change-Id: Iea4d2029723529444b93d7deca58824e592d0e0f
In order to radically simplify how we prepare the service
venvs, we use a common role to do the wheel builds and the
venv preparation. This makes the process far simpler to
understand, because the role does its own building and
installing. It also reduces the code maintenance burden,
because instead of duplicating the build processes in the
repo_build role and the service role - we only have it all
done in a single place.
We also change the role venv tag var to use the integrated
build's common venv tag so that we can remove the role's
venv tag in group_vars in the integrated build. This reduces
memory consumption and also reduces the duplication.
This is by no means the final stop in the simplification
process, but it is a step forward. The will be work to follow
which:
1. Replaces 'developer mode' with an equivalent mechanism
that uses the common role and is simpler to understand.
We will also simplify the provisioning of pip install
arguments when doing this.
2. Simplifies the installation of optional pip packages.
Right now it's more complicated than it needs to be due
to us needing to keep the py_pkgs plugin working in the
integrated build.
3. Deduplicates the distro package installs. Right now the
role installs the distro packages twice - just before
building the venv, and during the python_venv_build role
execution.
Depends-On: https://review.openstack.org/598957
Change-Id: I29833c41eba9b3ff80200b7f567a120f589e170e
Implements: blueprint python-build-install-simplification
Signed-off-by: Jesse Pretorius <jesse.pretorius@rackspace.co.uk>
This removes the systemd service templates and tasks from this role and
leverages a common systemd service role instead. This change removes a
lot of code duplication across all roles all without sacrificing features
or functionality. The intention of this change is to ensure uniformity and
reduce the maintenance burden on the community when sweeping changes are
needed.
The systemd journal would normally be populated with the standard out of
a service however with the use of uwsgi this is not actually happening
resulting in us only capturing the logs from the uwsgi process instead
of the service itself. This change implements journal logging in the
service config, which is part of OSLO logging.
OSLO logging docs found here: <https://docs.openstack.org/oslo.log/3.28.1/journal.html>
Change-Id: I9764f557007d97cfcbe02abf7166cce423b39a31
Signed-off-by: Kevin Carter <kevin.carter@rackspace.com>
With the more recent versions of ansible, we should now use
"is" instead of the "|" sign for the tests.
This should fix it.
Change-Id: I52808859f84e18c5f906dd7bcf2e30a9a155de99
From Ansible 2.2 onwards, listen can be used for
handlers instead of chaining notifiers. The
handlers are then executed in the sequence
present in the handler file.
Change-Id: I48f919d55a30ca136207551ea9f2da691fd18475
Due to the debug message plugin the handler restart
messages show at the end of the playbook execution
which is a little confusing. Using debug also
requires setting changed_when to true which is a
little extra bit of code which we do not have to
carry.
Instead we use the command module which is simple,
works and less wordy.
Change-Id: Ic80a23df0d86258ae7931ebb0dea2bcea97187a2
When the policy file is copied from the templated
file to the active file, it loses its group/mode
settings. This patch ensures that they are properly
replicated during the copy.
Change-Id: I727d8952259cf65a89e8b78cbb5e909d1ee32f84
The policy.json file is currently read continually by the
services and is not only read on service start. We therefore
cannot template directly to the file read by the service
(if the service is already running) because the new policies
may not be valid until the service restarts. This is
particularly important during a major upgrade. We therefore
only put the policy file in place after the service restart.
This patch also tidies up the handlers and some of the install
tasks to simplify them and reduce the tasks/code a little.
Change-Id: I7c7d9c23ff2c7f2355991576ed17d2fba8a0721c
Change the 'designate_service_names' from a list to a dictionary mapping
of services, groups that install those services. This brings the
method into line with that used in the os_neutron role in order to
implement a more standardised method.
The init tasks have been updated to run once and loop through this
mapping rather than being included multiple times and re-run against
each host. This may potentially reduce role run times.
Currently the reload of upstart/systemd scripts may not happen if
only one script changes as the task uses a loop with only one result
register. This patch implements handlers to reload upstart/systemd
scripts to ensure that this happens when any one of the scripts
change.
The handler to reload the services now only tries to restart the
service if the host is in the group for the service according to the
service group mapping. This allows us to ensure that handler
failures are no longer ignored and that no execution time is wasted
trying to restart services which do not exist on the host.
Finally:
- Common variables shared by each service's template files have
been updated to use the service namespaced variables.
- Unused handlers have been removed.
- Unused variables have been removed.
Change-Id: I8b3df067d5e27711d9f962d74932c818a506e77a
Update documentation, default variables, tasks, and environment
inventory to include installation of the designate-zone-manager service.
Change-Id: I1a72cad13e88d962a1e38793a1a3b5b35c0ba8b7
This patch removes unnecessary whitespace and converts Windows
CR's to Unix LF's.
It also makes a small change to the default description for
Designate in the Keystone service catalogue to ensure that it
is more consistent with other services in OpenStack-Ansible.
Damian Dabrowski