Open Stack

Sorry to everyone for bringing up this old thread, but it seems we may need
more openstackclient/keystone experts to settle this.

I'm referring to the comments in https://review.openstack.org/#/c/207873/
Specifically comments from Richard Megginson and Gilles Dubreuil indicating
openstackclient behavior for v3 keystone API.


A few items seem to be under dispute:
1 - Keystone should be able to accept v3 requests at
http://keystone-server:5000/
2 - openstackclient should be able to interpret v3 requests and append
"v3/" to OS_AUTH_URL=http://keystone-server.5000/ or rewrite the URL if it
is set as OS_AUTH_URL=http://keystone-server.5000/
3 - All deployments require /etc/keystone/keystone.conf with a token (and
not simply use openrc for creating additional endpoints, users, etc beyond
keystone itself and an admin user)

I believe it should be possible to set v2.0 keystone OS_AUTH_URL in openrc
and puppet-keystone + puppet-openstacklib should be able to make v3
requests sensibly by manipulating the URL.
Additionally, creating endpoints/users/roles shouldbe possible via openrc
alone. It's not possible to write single node tests that can demonstrate
this functionality, which is why it probably went undetected for so long.

If anyone can speak up on these items, it could help influence the outcome
of this patch.

Thank you for your time.

Best Regards,
Matthew Mosesohn

On Fri, Jul 31, 2015 at 6:32 PM, Rich Megginson <rmeggins at redhat.com> wrote:

> On 07/31/2015 07:18 AM, Matthew Mosesohn wrote:
>
>> Jesse, thanks for raising this. Like you, I should just track upstream
>> and wait for full V3 support.
>>
>> I've taken the quickest approach and written fixes to
>> puppet-openstacklib and puppet-keystone:
>> https://review.openstack.org/#/c/207873/
>> https://review.openstack.org/#/c/207890/
>>
>> and again to Fuel-Library:
>> https://review.openstack.org/#/c/207548/1
>>
>> I greatly appreciate the quick support from the community to find an
>> appropriate solution. Looks like I'm just using a weird edge case
>> where we're creating users on a separate node from where keystone is
>> installed and it never got thoroughly tested, but I'm happy to fix
>> bugs where I can.
>>
>
> Most puppet deployments either realize all keystone resources on the
> keystone node, or drop an /etc/keystone/keystone.conf with admin token onto
> non-keystone nodes where additional keystone resources need to be realized.
>
>
>
>> -Matthew
>>
>> On Fri, Jul 31, 2015 at 3:54 PM, Jesse Pretorius
>> <jesse.pretorius at gmail.com> wrote:
>>
>>> With regards to converting all services to use Keystone v3 endpoints,
>>> note
>>> the following:
>>>
>>> 1) swift-dispersion currently does not support consuming Keystone v3
>>> endpoints [1]. There is a patch merged to master [2] to fix that, but a
>>> backport to kilo is yet to be done.
>>> 2) Each type (internal, admin, public) of endpoint created with the
>>> Keystone
>>> v3 API has its own unique id, unlike with the v2 API where they're all
>>> created with a single ID. This results in the keystone client being
>>> unable
>>> to read the catalog created via the v3 API when querying via the v2 API.
>>> The
>>> solution is to use the openstack client and to use the v3 API but this
>>> obviously needs to be noted for upgrade impact and operators.
>>> 3) When glance is setup to use swift as a back-end, glance_store is
>>> unable
>>> to authenticate to swift when the endpoint it uses is a v3 endpoint.
>>> There
>>> is a review to master in progress [3] to fix this which is unlikely to
>>> make
>>> it into kilo.
>>>
>>> We (the openstack-ansible/os-ansible-deployment project) are tracking
>>> these
>>> issues and doing tests to figure out all the bits. These are the bugs
>>> we've
>>> hit so far. Also note that there is a WIP patch to gate purely on
>>> Keystone
>>> v3 API's which is planned to become voting (hopefully) by the end of this
>>> cycle.
>>>
>>> [1] https://bugs.launchpad.net/swift/+bug/1468374
>>> [2] https://review.openstack.org/195131
>>> [3] https://review.openstack.org/193422
>>>
>>>
>>> __________________________________________________________________________
>>> OpenStack Development Mailing List (not for usage questions)
>>> Unsubscribe:
>>> OpenStack-dev-request at lists.openstack.org?subject:unsubscribe
>>> http://lists.openstack.org/cgi-bin/mailman/listinfo/openstack-dev
>>>
>>>
>> __________________________________________________________________________
>> OpenStack Development Mailing List (not for usage questions)
>> Unsubscribe:
>> OpenStack-dev-request at lists.openstack.org?subject:unsubscribe
>> http://lists.openstack.org/cgi-bin/mailman/listinfo/openstack-dev
>>
>
>
> __________________________________________________________________________
> OpenStack Development Mailing List (not for usage questions)
> Unsubscribe: OpenStack-dev-request at lists.openstack.org?subject:unsubscribe
> http://lists.openstack.org/cgi-bin/mailman/listinfo/openstack-dev
>
-------------- next part --------------
An HTML attachment was scrubbed...
URL: <http://lists.openstack.org/pipermail/openstack-dev/attachments/20150810/04101bb3/attachment.html>