Open Stack

On Wed, Jul 16, 2014 at 11:24 AM, Joe Gordon <joe.gordon0 at gmail.com> wrote:

>
>
>
> On Tue, Jul 15, 2014 at 7:20 AM, Morgan Fainberg <
> morgan.fainberg at gmail.com> wrote:
>
>>
>>
>> On Tuesday, July 15, 2014, Steven Hardy <shardy at 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 at lists.openstack.org
>> 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/20140716/c2904e92/attachment.html>