I apologize for the very mixed up/missed quoting in that response, looks like my client ate a bunch of the quotes when writing up the email.
— Morgan Fainberg ------------------------------------------------------ From: Morgan Fainberg morgan.fainb...@gmail.com Reply: Morgan Fainberg morgan.fainb...@gmail.com Date: July 16, 2014 at 07:34:57 To: OpenStack Development Mailing List (not for usage questions) openstack-dev@lists.openstack.org Subject: [openstack-dev] [devstack][keystone] Devstack, auth_token and keystone v3 > > > On Wednesday, July 16, 2014, Joe Gordon wrote: > > > > On Tue, Jul 15, 2014 at 7:20 AM, Morgan Fainberg wrote: > > > On Tuesday, July 15, 2014, Steven Hardy wrote: > On Mon, Jul 14, 2014 at 02:43:19PM -0400, Adam Young wrote: > > On 07/14/2014 11:47 AM, Steven Hardy wrote: > > >Hi all, > > > > > >I'm probably missing something, but can anyone please tell me when devstack > > >will be moving to keystone v3, and in particular when API auth_token will > > >be configured such that auth_version is v3.0 by default? > > > > > >Some months ago, I posted this patch, which switched auth_version to v3.0 > > >for Heat: > > > > > >https://review.openstack.org/#/c/80341/ > > > > > >That patch was nack'd because there was apparently some version discovery > > >code coming which would handle it, but AFAICS I still have to manually > > >configure auth_version to v3.0 in the heat.conf for our API to work > > >properly with requests from domains other than the default. > > > > > >The same issue is observed if you try to use non-default-domains via > > >python-heatclient using this soon-to-be-merged patch: > > > > > >https://review.openstack.org/#/c/92728/ > > > > > >Can anyone enlighten me here, are we making a global devstack move to the > > >non-deprecated v3 keystone API, or do I need to revive this devstack patch? > > > > > >The issue for Heat is we support notifications from "stack domain users", > > >who are created in a heat-specific domain, thus won't work if the > > >auth_token middleware is configured to use the v2 keystone API. > > > > > >Thanks for any information :) > > > > > >Steve > > There are reviews out there in client land now that should work. I was > > testing discover just now and it seems to be doing the right thing. If the > > AUTH_URL is chopped of the V2.0 or V3 the client should be able to handle > > everything from there on forward. > > Perhaps I should restate my problem, as I think perhaps we still have > crossed wires: > > - Certain configurations of Heat *only* work with v3 tokens, because we > create users in a non-default domain > - Current devstack still configures versioned endpoints, with v2.0 keystone > - Heat breaks in some circumstances on current devstack because of this. > - Adding auth_version='v3.0' to the auth_token section of heat.conf fixes > the problem. > > So, back in March, client changes were promised to fix this problem, and > now, in July, they still have not - do I revive my patch, or are fixes for > this really imminent this time? > > Basically I need the auth_token middleware to accept a v3 token for a user > in a non-default domain, e.g validate it *always* with the v3 API not v2.0, > even if the endpoint is still configured versioned to v2.0. > > Sorry to labour the point, but it's frustrating to see this still broken > so long after I proposed a fix and it was rejected. > > > We just did a test converting over the default to v3 (and falling back to v2 > as needed, yes > fallback will still be needed) yesterday (Dolph posted a couple of test > patches and they > seemed to succeed - yay!!) It looks like it will just work. Now there is a > big caveate, this > default will only change in the keystone middleware project, and it needs to > have a patch > or three get through gate converting projects over to use it before we accept > the code. > > Nova has approved the patch to switch over, it is just fighting with Gate. > Other patches > are proposed for other projects and are in various states of approval. > > I assume you mean switch over to keystone middleware project [0], not switch > over to keystone > v3. Based on [1] my understanding is no changes to nova are needed to use the > v2 compatible > parts of the v3 API, But are changes needed to support domains or is this not > a problem because > the auth middleware uses uuids for user_id and project_id, so nova doesn't > need to have > any concept of domains? Are any nova changes needed to support the v3 API? > > > > This change simply makes it so the middleware will prefer v3 over v2 if both > are available > for validating UUID tokens and fetching certs. It still falls back to v2 as > needed. It > is transparent to all services (it was blocking on Nova and some uniform > catalog related > issues a while back, but Jamie Lennox resolved those, see below for more > details). > > It does not mean Nova (or anyone else) are magically using features they > weren't already > using. It just means Heat isn't needing to do a bunch of conditional stuff to > get the V3 > information out of the middleware. This change is only used in the case that > V2 and V3 are > available when auth_token middleware looks at the auth_url (limited > discovery). It > is still possible to force V2 by setting the ‘identity_uri' to the V2.0 > specific root > (no discovery performed). > > Switching over the default to v3 in the middleware doesn't test nova + v3 > user tokens, > tempest nova tests don't generate v3 user tokens (although I hear there is an > experimental > job to do this). So you are testing that moving the middleware to v3 but > accepting v2 API > user tokens works. But what happens if someone tries to use a the non-default > domain? > Or using other v3 only features? Switching over to v3 for the middleware > without actually > testing any v3 user facing features sounds like a big testing gap. > I agree that we should increase our testing for V3 (specifically in tempest). > The question > as to what happens when a non-default-domain token is passed to Nova has the > same answer > as if a PKI token with a non-default domain is passed to Nova via the > middleware. The logic > in handling a V3 token vs a V2 token has not changed in that regard. > > The biggest difference between a V2 and V3 token once it gets past the > auth_token middleware > is the catalog. This is addressed with > https://github.com/openstack/keystonemiddleware/blob/master/keystonemiddleware/auth_token.py#L975-L976 > > . We build the header values passed from the middleware here: > https://github.com/openstack/keystonemiddleware/blob/master/keystonemiddleware/auth_token.py#L932-L967 > > . This will pull the values from known locations from the token, meaning that > the headers > should be the same regardless of token version (with exception of the catalog > and we’re > doing conversions now). If the application doesn’t use the data from the > header, (some > v3-specific values), it shouldn’t affect anything . > > I see the keystone middleware patch has landed [3] > > Please note that this does not mean we have *released* the updated > keystonemiddleware > package. The current released version does not have this change. This change > is an important > one on the road to getting us to V3 across the board. > > > [0] https://review.openstack.org/#/c/102342/ > [1] http://docs.openstack.org/developer/keystone/http-api.htm > [2] > http://git.openstack.org/cgit/openstack/nova/tree/nova/db/sqlalchemy/models.py#n200 > > [3] https://review.openstack.org/#/c/106819 > > > I hope this has helped with some of the concerns on how this impacts Nova and > other services. > > Cheers, > > Morgan > > > > > _______________________________________________ OpenStack-dev mailing list OpenStack-dev@lists.openstack.org http://lists.openstack.org/cgi-bin/mailman/listinfo/openstack-dev