Open Stack

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.


> 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
>
>
-------------- next part --------------
An HTML attachment was scrubbed...
URL: <http://lists.openstack.org/pipermail/openstack-dev/attachments/20140717/98a739f1/attachment.html>