Open Stack

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?

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