Bug 1425533 - [RFE] Option to configure Keystone v3 on OSP deployment via the Director
Summary: [RFE] Option to configure Keystone v3 on OSP deployment via the Director
Alias: None
Product: Red Hat OpenStack
Classification: Red Hat
Component: instack-undercloud
Version: 12.0 (Pike)
Hardware: noarch
OS: Linux
Target Milestone: Upstream M2
: 12.0 (Pike)
Assignee: James Slagle
QA Contact: Arik Chernetsky
: 1434923 1434928 (view as bug list)
Depends On:
Blocks: 1335596 1356451 1426284 1434928 1434929 1434931 1442136 1469330
TreeView+ depends on / blocked
Reported: 2017-02-21 16:43 UTC by Irina Petrova
Modified: 2020-06-11 13:19 UTC (History)
21 users (show)

Fixed In Version: instack-undercloud-7.0.0-0.20170503001109.el7ost
Doc Type: If docs needed, set a value
Doc Text:
Clone Of:
Last Closed: 2017-12-13 21:08:54 UTC
Target Upstream Version:

Attachments (Terms of Use)

System ID Private Priority Status Summary Last Updated
Red Hat Knowledge Base (Solution) 2619771 0 None None None 2017-02-22 07:44:00 UTC
Red Hat Product Errata RHEA-2017:3462 0 normal SHIPPED_LIVE Red Hat OpenStack Platform 12.0 Enhancement Advisory 2018-02-16 01:43:25 UTC

Description Irina Petrova 2017-02-21 16:43:26 UTC
Description of problem:

We have customers that would like tested production-ready Director templates that deploy RHOS with Keystone v3 by default (v3 is not only installed/available but also pre-configured for use by the other OSP services).

I know it is a broad RFE (since I am not specifying which services are expected to work with Keystone v3) but having some supported options (that passed QE tests) would be nice.

Also, at the moment it is not clear (I cannot find any documentation on) which services can talk to Keystone v3 API. We have a manual guide for Nova and Cinder [1] but what about the rest?

Creating a Director-driven framework that would be updated on each release is a good way of pushing v3 to the environment and keeping it consistent during the upgrades that will follow. Because even though we might be able to create and offer some lab-tested templates, it does not mean that we can carry them on through the OSP versions. It's much better if we can have a centralized (as in 'coming with the product') solution that we can keep track of.

[1] https://access.redhat.com/documentation/en-us/red_hat_openstack_platform/10/html-single/integrate_with_identity_service/#enable_command_line_access_to_keystone_v3_3

Comment 7 Emilien Macchi 2017-04-03 21:22:37 UTC
Work can be tracked here: https://blueprints.launchpad.net/tripleo/+spec/keystone-v3

Comment 8 Nathan Kinder 2017-04-27 20:40:11 UTC
This looks mostly complete upstream:


The only outstanding review appears to be for having stackrc use v3 in instack-undercloud.

Is there anything else outstanding that is still using the v2 Identity API?

Comment 9 Juan Antonio Osorio 2017-04-28 06:15:55 UTC
Well, the undercloud commit is not really just the stackrc but a bunch of services whose API we use v2 for. Hopefully that patch is merging soon as we got finally a release for mistralclient which is what we needed to make that work.

Comment 11 Nathan Kinder 2017-05-26 17:41:06 UTC
*** Bug 1434928 has been marked as a duplicate of this bug. ***

Comment 12 Nathan Kinder 2017-05-26 17:44:52 UTC
*** Bug 1434923 has been marked as a duplicate of this bug. ***

Comment 18 errata-xmlrpc 2017-12-13 21:08:54 UTC
Since the problem described in this bug report should be
resolved in a recent advisory, it has been closed with a
resolution of ERRATA.

For information on the advisory, and where to find the updated
files, follow the link below.

If the solution does not work for you, open a new bug report.


Note You need to log in before you can comment on or make changes to this bug.