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