Open Stack

On 08/10/2015 07:46 AM, Matthew Mosesohn wrote:
> 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/

I don't think so.  Keystone requires the version suffix "/v2.0" or "/v3".

> 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/

It does, if it can determine from the given authentication arguments if 
it can do v3 or v2.0.

> 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)

No.  What I said about this issue was "Most people using 
puppet-keystone, and realizing Keystone resources on nodes that are not 
the Keystone node, put a /etc/keystone/keystone.conf on that node with 
the admin_token in it."

That doesn't mean the deployment requires /etc/keystone/keystone.conf.  
It should be possible to realize Keystone resources on non-Keystone 
nodes by using ENV or openrc or other means.

>
> 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.

Yes.  Because for the puppet-keystone resource providers, they are coded 
to a specific version of the api, and therefore need to be able to 
set/override the OS_IDENTITY_API_VERSION and the version suffix in the URL.

> Additionally, creating endpoints/users/roles shouldbe possible via 
> openrc alone.

Yes.

> It's not possible to write single node tests that can demonstrate this 
> functionality, which is why it probably went undetected for so long.

And since this is supported, we need tests for this.
>
> 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 
> <mailto: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 <mailto: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://OpenStack-dev-request@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://OpenStack-dev-request@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://OpenStack-dev-request@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/39959af4/attachment.html>