Open Stack

On Thu, Jul 17, 2014 at 7:17 AM, Dolph Mathews <dolph.mathews at gmail.com>
wrote:

>
> On Thu, Jul 17, 2014 at 7:56 AM, Joe Gordon <joe.gordon0 at gmail.com> wrote:
>
>>
>>
>>
>> On Wed, Jul 16, 2014 at 5:07 PM, Morgan Fainberg <
>> morgan.fainberg at gmail.com> wrote:
>>
>>> Reposted now will a lot less bad quote issues. Thanks for being patient
>>> with the re-send!
>>>
>>> ------------------------------------------------------
>>> From: Joe Gordon joe.gordon0 at gmail.com
>>> Reply: OpenStack Development Mailing List (not for usage questions)
>>> openstack-dev at lists.openstack.org
>>> Date: July 16, 2014 at 02:27:42
>>> To: OpenStack Development Mailing List (not for usage questions)
>>> openstack-dev at 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 at lists.openstack.org
>> http://lists.openstack.org/cgi-bin/mailman/listinfo/openstack-dev
>>
>>
>
> _______________________________________________
> 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/20140722/ca6a5091/attachment.html>