Merge "Add spec for enabling Keystone v3 API by default"
This commit is contained in:
Zuul
Gerrit Code Review
commit
57887e9fc8
|
|
@ -0,0 +1,146 @@
|
|||
..
|
||||
Copyright 2017 Canonical Ltd.
|
||||
|
||||
This work is licensed under a Creative Commons Attribution 3.0
|
||||
Unported License.
|
||||
http://creativecommons.org/licenses/by/3.0/legalcode
|
||||
|
||||
..
|
||||
This template should be in ReSTructured text. Please do not delete
|
||||
any of the sections in this template. If you have nothing to say
|
||||
for a whole section, just write: "None". For help with syntax, see
|
||||
http://sphinx-doc.org/rest.html To test out your formatting, see
|
||||
http://www.tele3.cz/jbar/rest/rest.html
|
||||
|
||||
===============================================
|
||||
Keystone - Change default preferred API version
|
||||
===============================================
|
||||
|
||||
The current default preferred API version used by the Keystone Charm is v2.0.
|
||||
|
||||
There exists multiple use cases where the use of the v3 API is required.
|
||||
To use features such as domains, domain specific drivers, LDAP authentication,
|
||||
Federation (OpenID Connect, SAML) and others not mentioned, the Keystone V3
|
||||
API endpoints must be exposed in the catalog and all services in a deployment
|
||||
must leverage the V3 API when authenticating with Keystone. Increasingly so
|
||||
these use cases would be the desired mode of operation for new OpenStack
|
||||
deployments.
|
||||
|
||||
Additionally the v2.0 API has been marked as DEPRECATED since the OpenStack
|
||||
Mitaka release and will be REMOVED in the Queens release cycle.
|
||||
|
||||
Problem Description
|
||||
===================
|
||||
|
||||
The Keystone charm currently has two separate code paths for managing the
|
||||
Keystone service. Which path is exercised depends on the value of the
|
||||
'preferred-api-version' setting. This leads to duplication of both code, and
|
||||
potential bugs.
|
||||
|
||||
The majority of our functional tests are currently run with services configured
|
||||
to talk to Keystone using the v2.0 API.
|
||||
|
||||
Change of endpoints in the Keystone catalog and reconfiguration of services to
|
||||
use the v3 API automatically in already running deployments may lead to
|
||||
unforeseen and undesirable side effects. We must find a way to have the change
|
||||
of default affect new deployments only, and leave existing deployments
|
||||
untouched on charm upgrade.
|
||||
|
||||
Proposed Change
|
||||
===============
|
||||
|
||||
Remove API v2.0 specific code from 'hooks/manager.py' and make use of a
|
||||
combination of the 'keystone-manage' CLI tool and the v3 API to manage Keystone
|
||||
service regardless of the value of 'preferred-api-version' configuration
|
||||
option.
|
||||
|
||||
Re-wire existing unit- and functional- tests to be performed on deployments
|
||||
configured to use both v2.0 and v3 API. This induces change in both the
|
||||
keystone charm itself as well as any other charm with specific tests for how
|
||||
it relates to the keystone charm.
|
||||
|
||||
Remove default value for 'preferred-api-version' in config.yaml and let charm
|
||||
decide which default to use programatically. The upgrade function should be
|
||||
made to retain 'preferred-api-version' as 2 for existing deployments that makes
|
||||
use of the current default.
|
||||
|
||||
Version fence will be implemented in charm to have the new default apply for
|
||||
OpenStack versions 'Queens' and onwward.
|
||||
|
||||
Alternatives
|
||||
------------
|
||||
|
||||
There are no real alternatives. Not changing the default would make our test
|
||||
coverage poorer for the real world use cases that our software is currently
|
||||
exposed to.
|
||||
|
||||
Implementation
|
||||
==============
|
||||
|
||||
Assignee(s)
|
||||
-----------
|
||||
|
||||
Primary assignee:
|
||||
fnordahl
|
||||
|
||||
Gerrit Topic
|
||||
------------
|
||||
|
||||
Use Gerrit topic "keystone-v3" for all patches related to this spec.
|
||||
|
||||
.. code-block:: bash
|
||||
|
||||
git-review -t keystone-v3
|
||||
|
||||
Work Items
|
||||
----------
|
||||
|
||||
- Update 'hooks/manager.py' to use a combination of keystone-manage CLI and
|
||||
v3 API to manage the Keystone deployment. Remove any v2.0 API specifc code.
|
||||
This work item should include removal of dependency on having admin-token in
|
||||
Keystone configuration file and to switch charm over to use keystoneauth1
|
||||
with sessions.
|
||||
- Update relevant functions in charmhelpers.contrib.openstack.amulet.utils
|
||||
- Make all existing unit- and functional- tests run on both v2.0 API and v3 API
|
||||
configured deployments in the gate.
|
||||
- Implement version fence that applies the new default for OpenStack release
|
||||
'Queens' and onward.
|
||||
- Remove default value for 'preferred-api-version', make decision in charm
|
||||
programatically.
|
||||
- Make sure simplestreams with Keystone v3 API support is backported to our
|
||||
stable releases.
|
||||
|
||||
Repositories
|
||||
------------
|
||||
|
||||
No new git repositories required.
|
||||
|
||||
Documentation
|
||||
-------------
|
||||
|
||||
This change calls for an update of the documentation in README.md with
|
||||
information about how the charm sets up domains and projects in a v3 API
|
||||
enabled Keystone deployment. The documentation should also include examples of
|
||||
openrc files and simple openstack client usage.
|
||||
|
||||
Security
|
||||
--------
|
||||
|
||||
We are exercising existing code paths and are changing the default value of
|
||||
how the Keystone deployment is configured to match real world usage, we are not
|
||||
introducing new changes that have security implications. Revisiting and
|
||||
re-validating the security of the existing implementation is in place as a part
|
||||
of this work.
|
||||
|
||||
Testing
|
||||
-------
|
||||
|
||||
Implementation will update existing unit- and functional- tests to leverage
|
||||
both v2.0 and v3 API configurations. Scripts, bundles and specs used in
|
||||
periodic and pre-release testing should also be updated to handle and
|
||||
excercise the new default.
|
||||
|
||||
Dependencies
|
||||
============
|
||||
|
||||
No external dependencies.
|
||||
Loading…
Reference in New Issue