Commit Graph

9 Commits

Author SHA1 Message Date
Jonathan Rosser 14a2bd072c Migrate ssl certificate generation to the PKI role
This is now common functionality in an ansible role, rather than
being implemented directly in openstack-ansible service roles.

This patch creates the apache server certificate and key using the
pki role when keystone_ssl is true.

A CA certificate and key are generated and installed when keystone
is configured to be an IDP, triggered by keystone_idp.certfile being
defined.

Depends-On: https://review.opendev.org/c/openstack/ansible-role-pki/+/830794
Change-Id: Ie70aecc93b8acb7c1bbad02e98254b7c50c4c86f
2022-03-10 09:58:39 +00:00
Logan V 5e23c765b3 Add external LB management handler hook interface
Based on conversation on an ansible issue[1], I implemented
a LB orchestration role[2] similar to the POC here[3].

This will allow external loadbalancer management roles to hook
into a universal notify listener "Manage LB" to perform before/
after endpoint management actions when the service is being
restarted.

[1]: https://github.com/ansible/ansible/issues/27813
[2]: https://github.com/Logan2211/ansible-haproxy-endpoints
[3]: https://github.com/Logan2211/tmp-ansible-27813

Change-Id: Ide9efbc79e4fd2c761a3ee4f463f501181da1df2
2017-09-16 13:41:28 -05:00
Jesse Pretorius aad8144bfb Implement serialisable rolling upgrade
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
2017-06-19 19:32:45 +00:00
Jesse Pretorius 94293c86c2 Perform an atomic policy file change
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
2017-04-04 10:49:52 +01:00
Jimmy McCrory 04737f5dbd Implement zero downtime upgrades
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
2016-11-17 08:10:57 -08:00
Kevin Carter 0de819e92a Implement CentOS 7 support in os_keystone
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>
2016-08-29 14:20:48 +00:00
Travis Truman 8797fc707a Cleanup/standardize usage of tags
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
2016-05-24 15:51:03 -04:00
Lance Bragstad 7e14932dc4 Use ansible facts for distributing SSL certs/keys
The os_keystone role previously relied on a memcached deployment to transfer
SSL certificates and keys to all keystone nodes. Many of the openstack-ansible
repositories have refactored this behavior out in place of registering the
certificates and keys as ansible facts and using ansible's copy module to
transfer them to each node in the deployment.

This breaks the dependency of requiring memcached in order to deploy keystone
with SSL.

Change-Id: I8db39a2a4a54aa9814c1b05988f05bfcae94f222
2016-04-11 18:32:50 +00:00
Jesse Pretorius bfb378f19b Keystone SSL cert/key distribution and configuration
This patch adds the option to provide an SSL certificate for the
Keystone service (either self-signed or user provided) and to
configure the endpoints and Keystone service appropriately.

* A new boolean variable called 'keystone_ssl' enables/disables
  the configuration of SSL for the Keystone service.

* The server key/certificate (and optionally a CA cert) are
  distributed to all keystone containers and used for the setup
  of SSL endpoints if the appropriate protocol is set.

* The internal/public and the admin endpoints can be set to be
  served via http or https seperately via the
  'keystone_service_*_proto' variables.

* The logic to determine the appropriate load balancing
  configuration based on the Keystone endpoint protocol has
  been implemented in the haproxy vars.

* Two new variables have been implemented for a user-provided
  server key and certificate:
  - keystone_user_ssl_cert: <path to cert on deployment host>
  - keystone_user_ssl_key: <path to cert on deployment host>
  If either of these is not defined, but a Keystone endpoint
  has been configured for SSL, then the missing cert/key
  will be self generated on the first Keystone container and
  distributed to the other containers.

* A new variable has been implemented for a user-provided CA
  certificate:
  - keystone_user_ssl_ca_cert: <path to cert on deployment host>

* A new variable called 'keystone_ssl_self_signed_subject' has
  been implemented to allow the user to override the certificate
  properties, such as the CN and subjectAltName.

Upgrade notes:

* The SSL-based client authentication configuration in Apache
  has been removed as it appears to be unused.

* The minimum Ansible version for the os_keystone and
  haproxy_server roles have been increased to v1.9.0 as it's
  the minimum version that supports ternary filters.

* The boolean 'keystone_ssl_enabled' has been renamed to
  'keystone_ssl'. This maintains a pattern set in the haproxy
  role for enablement of ssl offloading in the load balancer.

* The Apache configuration appropriately implements the
  'SSLCACertificateFile' instead of the 'SSLCACertificatePath'
  directive in order to ensure that the appropriate signing
  certificate is provided to the browser.

* The 'keystone_self_signed_regen' variable has been renamed
  to 'keystone_ssl_self_signed_regen'.

* The default names for the deployed keys/certificates have been
  changed:
  - /etc/ssl/certs/apache.cert  > /etc/ssl/certs/keystone.pem
  - /etc/ssl/private/apache.key > /etc/ssl/private/keystone.key

DocImpact
Partial-Bug: #1466827
Implements: blueprint keystone-federation
Change-Id: I4c5ea7b6bfc3d7d7230a7440fa501241826c9dee
Co-Authored-By: Miguel Grinberg <miguelgrinberg50@gmail.com>
2015-08-19 07:51:09 +00:00