Open Stack

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.

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