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
This change implements CentOS 7 support within the os_keystone role.
Depends-on: I333fb1887339e8dc9ebf10ff137dda3cff629dc0
Change-Id: Ib339cd0657f7008fa48bf74f8d6ddd4b8add2ea1
Signed-off-by: Kevin Carter <kevin.carter@rackspace.com>
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
The numerous tags within the role have been condensed
to two tags: keystone-install and keystone-config
These tags have been chosen as they are namespaced
and cover the two major functions of the role.
Documentation has been updated to inform how each tag
influences the function of the role.
Change-Id: Iea4bff944ce0a35a4b1bc044171472ea44eda323
ansible-lint 2.3.7 added a rule checking for use of the deprecated
'sudo' and 'sudo_user' directives. They have been replaced with 'become'
and 'become_user' respectively.
Change-Id: I2271fe8468840884f19f41abba37e696c6296350
This commit conditionally allows the os_keystone role to
install build and deploy within a venv. This is the new
default behavior of the role however the functionality
can be disabled.
Change-Id: Ie9e51926c96125a543e05eaa1912684fb01fecda
Implements: blueprint enable-venv-support-within-the-roles
Signed-off-by: Kevin Carter <kevin.carter@rackspace.com>
This change adds the bits necessary to configure Keystone as an
identity provider (IdP) for an external service provider (SP).
* New variables to configure Keystone as an identity provider are now
supported under a root `keystone_idp` variable. Example configurations
can be seen in Keystone's defaults file. This configuration includes
the location of the signing certificate, authentication endpoints and
list of allowed service providers.
* xmlsec1 is installed in the Keystone containers when IdP configuration
is enabled.
* The IdP metadata and signing certiciate are generated and installed.
Implements: blueprint keystone-federation
Change-Id: I81455e593e3059633a55f7e341511d5ad9eba76f
Jonathan Rosser