On Wed, Jul 16, 2014 at 11:24 AM, Joe Gordon <joe.gord...@gmail.com> wrote:
> > > > On Tue, Jul 15, 2014 at 7:20 AM, Morgan Fainberg < > morgan.fainb...@gmail.com> wrote: > >> >> >> On Tuesday, July 15, 2014, Steven Hardy <sha...@redhat.com> 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? > > > 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 see the keystone middleware patch has landed [3] > I found the nova spec on this :https://review.openstack.org/#/c/103617/ > > > > [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 > > > >> >> So, in short. This is happening and soon. There are some things that need >> to get through gate and then we will do the release of keystonemiddleware >> that should address your problem here. At least my reading of the issue and >> the fixes that are pending indicates as much. (Please let me know if I am >> misreading anything here). >> >> 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