Instead of having own implementation of uwsgi, use common role.
This allows to reduce maintainable code and ease
providing fixes and features to uwsgi deployment code.
Change-Id: I2dc9c749c37e41959da2403fab7512ab17b859e4
This change sets the user argument in the cron module which is
required in future versions of ansible when the cron_file argument
is also used.
Filter deprecations for skipped items have also been fixed.
Change-Id: I803cd3c62707880e873662ea86590274b2766d21
Signed-off-by: Kevin Carter <kevin.carter@rackspace.com>
The change removes legacy files which conflict with new services being
deployed during a rolling upgrade. This change adds two tasks to remove
any legacy files should they be found and removes old cleanup handlers
that are no longer in service.
Change-Id: Ie593a80e0e6708c50f7809171fa47c7043a2e136
Signed-off-by: Kevin Carter <kevin.carter@rackspace.com>
There are times when a deployer will need to reconfigure parts of
an environment and having a general purpose tag to run said operation
will be important especicially should the deployer be needing to
reconfigure systemd unit files in a downtime event. This change adds
a general purpose systemd tag where include_role and systemd is found
which will assit operators with day2 operational tasks.
Change-Id: I61cc22441229258b77577fdba9f32597d0889031
Signed-off-by: Kevin Carter <kevin.carter@rackspace.com>
Tasks within the systemd_service role already handle looping over the
'systemd_services' list. The full list can be pre-created as passed as a
var so that the systemd_service role only needs to be included and run
once.
Change-Id: Ia46b5d61546252902b25933e8d5db4808c6de0b9
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.
In converting this role to use the common systemd_service role a
keystone_service dictionary was created in the defaults main.yml file.
This change follows the pattern of other services.
Change-Id: I65902f2483ef2f18ac2d229c5ebd9d090b6ae040
Signed-off-by: Kevin Carter <kevin.carter@rackspace.com>
Until all the roles are ready and have this new role in the
ansible-role-requirements, we should not be merging this. We
should also ensure that the integrated a-r-r includes this
role before merging this.
This reverts commit b42eef0dc4.
Change-Id: I8a944db87948ff783028240d3548016a52ab5af4
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.
In converting this role to use the common systemd_service role a
keystone_service dictionary was created in the defaults main.yml file.
This change follows the pattern of other services.
Change-Id: I70e1f6007d9f88f05ccdc737b210415274580a46
Signed-off-by: Kevin Carter <kevin.carter@rackspace.com>
This removes warnings in Ansible 2.4+.
The patch also removes "static:" from the playbooks since that
argument is no longer used by Ansible.
Change-Id: I6e5fcbccd4239db73de20e640a3423d1a2333bbe
Instead of providing vars to and including the keystone_init_systemd for
each keystone uwsgi program, loop over those program names within the
tasks.
This also prevents the /etc/tmpfiles.d/keystone.conf file from being
overwritten twice on every run.
Change-Id: I00dc80db7f6672fb26af0ec2301b3a4ea451844d
The current rolling upgrade implementation
relies on the role to orchestrate the rolling
upgrade. When the role is executed using
playbook serialisation, the db sync contract
is executed before all hosts are upgraded,
potentially resulting in data corruption.
This patch returns the role to the simpler,
best practice model of expecting that the role
is applied to a single host and that the
playbook handles orchestration. This method
can be used with any form of serialisation.
Depends-On: Ie90cdcbf9e73082a2074c8832b7490d188e178af
Change-Id: I5650f16b9a115bd392012b743788057a94d09226
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: Ie913e5eb75f3601107b53bab7bda4a02ab1c1024
This patch implements upgrading keystone with zero downtime as the
default installation process. Handlers have been modified to ensure that
the first keystone node is stopped, facilitates the database migrations,
and that it is started and available before restarting any other keystone
nodes. Migrations also now only occur when there is a change within the
installed keystone venv.
This process is documented at
http://docs.openstack.org/developer/keystone/upgrading.html#upgrading-without-downtime
A new test scenario has been added for testing basic upgradability
between releases.
Implements: blueprint upgrade-testing
Change-Id: I0d3cfcb80b64d005d60f4c8445f991855f844796
Release note is updated to describe this functionality as well as
general improvments for clarity.
Change-Id: I41838010fc4b6e892bec08035798f096aff5af8f
Related: blueprint keystone-uwsgi
When an Apache + mod_wsgi configuration is not selected, configure
the two Keystone services with uWSGI service profiles.
Two arbitrary ports are selected for uWSGI to listen on, so that it
may be proxied for by a dedicated web server. This is in preparation
for laying down Nginx in a future patch.
Notify events are updated to restart the Keystone uWSGI services
where Keystone's configuration is modified only. Because federation
concerns will be isolated within the dedicated web server, changes
to federation configuration of Shiboleth do not trigger restarts of
uWSGI. Similarly, SSL certificate changes do not trigger restarts.
Change-Id: I99e16a999c496e68fb25fa2630d9b211c9755ea4
Related: blueprint keystone-uwsgi
Dmitriy Rabotyagov