On Thu, Jul 17, 2014 at 7:17 AM, Dolph Mathews <dolph.math...@gmail.com> wrote:
> > On Thu, Jul 17, 2014 at 7:56 AM, Joe Gordon <joe.gord...@gmail.com> wrote: > >> >> >> >> On Wed, Jul 16, 2014 at 5:07 PM, Morgan Fainberg < >> morgan.fainb...@gmail.com> wrote: >> >>> Reposted now will a lot less bad quote issues. Thanks for being patient >>> with the re-send! >>> >>> ------------------------------------------------------ >>> From: Joe Gordon joe.gord...@gmail.com >>> Reply: OpenStack Development Mailing List (not for usage questions) >>> openstack-dev@lists.openstack.org >>> Date: July 16, 2014 at 02:27:42 >>> To: OpenStack Development Mailing List (not for usage questions) >>> openstack-dev@lists.openstack.org >>> Subject: Re: [openstack-dev] [devstack][keystone] Devstack, auth_token >>> and keystone v3 >>> >>> > 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 >>> >>> Correct, switch to middleware (a requirement before we landed this patch >>> in middleware). I was unclear in that statement. Sorry didn’t mean to make >>> anyone jumpy that something was approved in Nova that shouldn’t have been >>> or that did massive re-workings internal to Nova. >>> >>> > 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). >>> >> >> >> So this will be used in the gate? >> >> >>> >>> > >>> > 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). For 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. >>> >> >> I wasn't aware that PKI tokens had domains in them. What happens to nova >> in this case, It just works? >> > > Both PKI and UUID responses from v3 contain: > > 1. the user's domain > > And if it's a project scoped token: > > 2. the project's domain > > Or if it's a domain-scoped token: > > 3. a domain scope > > The answer to your question is that if nova receives a project-scoped > token (1 & 2), it doesn't need to be domain-aware: project ID's are > globally unique and nova doesn't need to know about project-domain > relationships. > > If nova receives a domain-scoped token (1 & 3), the policy layer can balk > with an HTTP 401 because there's no project in scope, and it's not > domain-aware. From nova's perspective, this is identical to the scenario > where the policy layer returns an HTTP 401 because nova was presented with > an unscoped token (1 only) from keystone. > You say the policy layer "can" balk with an HTTP 401. What is required to make this the default behavior in nova's policy layer? > > >> Based on >> https://review.openstack.org/#/c/103617/2/specs/juno/support-keystone-v3-api.rst >> it sounds like just switching over the keystonemiddleware and the >> novaclient to support keystone v3 nova will support keystone v3 (domains >> and all). But until a nova patch updates the neutron config section in >> nova, nova->neutron communication will be over keystone v2. Is that correct? >> >> >> >>> 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. >>> >> >> Ahh, thanks for the clarification. >> >> >>> >>> > >>> > [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 >> >> > > _______________________________________________ > OpenStack-dev mailing list > OpenStack-dev@lists.openstack.org > http://lists.openstack.org/cgi-bin/mailman/listinfo/openstack-dev > >
_______________________________________________ OpenStack-dev mailing list OpenStack-dev@lists.openstack.org http://lists.openstack.org/cgi-bin/mailman/listinfo/openstack-dev
