Rackspace authentication is broken

[Jason Dunsmore]

The following patch broke Rackspace authentication:
https://review.openstack.org/#/c/66649/

Rackspace doesn't have a v3 of its identity (keystone) service in production, so there will need to be an option to use v2 or v3.

[Steven Hardy (shardy)]

Setting this to opinion so we can discuss the way forward.

The keystone-v3-only BP is transitioning Heat to using the keystone v3 API exclusively, for the following reasons:
- Keystone are planning to deprecate the v2 API (in Juno)
- We currently have a horrible mixture of v2 and v3 in heat_keystoneclient to support trusts
- To fix bug #1089261 and implement bp instance-users, we need domains, which don't exist in v2

So I think we're doing the right thing by integrating with what is in Icehouse v3 Keystone for Heat Icehouse.

However I realize there may need to be some way for you to support a legacy/third-party solution while transitioning to Keystone, and we can discuss ways to enable that (without derailing the upstream roadmap).

One way which springs to mind is we make the client wrapper provided via heat_keystoneclient.py pluggable so you can plug in some alternative implementation (all our interaction with keystone except auth_token is abstracted via this wrapper class)

[Clint Byrum (clint-fewbar)]

Not sure Opinion is the right thing to set this to, as that effectively
removes it from the open bug list. If it needs to be discussed, Incomplete
or New seem more appropriate.

FWIW I agree 100% with your position btw Steven. I'd be entirely open
to anything that lets third parties plug in to Heat, but the core that
ships with OpenStack should support the release of OpenStack it ships
with and work as well as possible with the previous version. Seems we're
doing that.

Excerpts from Steven Hardy's message of 2014-01-29 17:27:17 UTC:
> Setting this to opinion so we can discuss the way forward.
>
> The keystone-v3-only BP is transitioning Heat to using the keystone v3 API exclusively, for the following reasons:
> - Keystone are planning to deprecate the v2 API (in Juno)
> - We currently have a horrible mixture of v2 and v3 in heat_keystoneclient to support trusts
> - To fix bug #1089261 and implement bp instance-users, we need domains, which don't exist in v2
>
> So I think we're doing the right thing by integrating with what is in
> Icehouse v3 Keystone for Heat Icehouse.
>
> However I realize there may need to be some way for you to support a
> legacy/third-party solution while transitioning to Keystone, and we can
> discuss ways to enable that (without derailing the upstream roadmap).
>
> One way which springs to mind is we make the client wrapper provided via
> heat_keystoneclient.py pluggable so you can plug in some alternative
> implementation (all our interaction with keystone except auth_token is
> abstracted via this wrapper class)
>
> ** Changed in: heat
> Status: New => Opinion
>
> --
> You received this bug notification because you are subscribed to heat.
> https://bugs.launchpad.net/bugs/1274201
>
> Title:
> Rackspace authentication is broken
>
> Status in Orchestration API (Heat):
> Opinion
>
> Bug description:
> The following patch broke Rackspace authentication:
> https://review.openstack.org/#/c/66649/
>
> Rackspace doesn't have a v3 of its identity (keystone) service in
> production, so there will need to be an option to use v2 or v3.
>
> To manage notifications about this bug go to:
> https://bugs.launchpad.net/heat/+bug/1274201/+subscriptions

[Steve Baker (steve-stevebaker)]

A v2 shim needs to be written, and this task is currently unassigned.

[Steven Hardy (shardy)]

Ok so to summarise the latest discussion on this topic:

- The heat_keystoneclient code in core heat will remain v3 only, because the keystone v2 API is deprecated (in Icehouse, and may be *removed* in Juno)
- An interface compatible v2 shim may be written (probably to live in contrib), which reimplements heat.common.heat_keystoneclient.KeystoneClient(), but this will probably mean those using the shim will still be affected by bug #1089261
- I'm committed to maintaining the core heat_keystoneclient, and improving our integration with upstream keystone, but due to the deprecation mentioned above, I personally will not be writing or maintaining this v2 shim, so someone else will have to step up if it is needed for the Rackspace-specific auth solution.

[Keith Bray (keith-bray)]

Steve, this isn't an issue due to a Rackspace-specific auth solution. This is a case of v2 Auth support vs v3 Auth support. If I understand correctly, v2 Auth IS supported in Icehouse. v2 is getting marked as deprecated by Keystone at Icehouse release, which means that after Icehouse lands other dependents should migrate off v2 in favor of v3 before Juno or whenever v2 gets decommissioned. Forcing Heat to v3 at Icehouse (before the deprecation lands) is premature. The result is that anyone (not just Rackspace) that currently uses auth v2 will not be able to use Icehouse version of Heat without a working shim or also updating their Keystone to Auth v3 at the same time they update Heat to Icehouse release of Heat. Auth v2 is being deprecated in Icehouse but not decommissioned in Icehouse, so it should be a supported configuration of an Icehouse Openstack deployment. I would encourage you to support v2 for one more release instead of putting others in an awkward position of having to shim stuff to fix forward looking dependencies when v2 should still be supported and work between Icehouse and Juno.

If I'm wrong on my assumptions, please let me know. I'm learning here :-) Thanks!

[Steve Baker (steve-stevebaker)]

Keith, v3 is enabled by default in Havana so until I'm presented with any evidence to the contrary I believe that this is an issue which only affects rackspace's heat.

Apart from describing a v2 shim as "awkward" I agree 100% with your arguments. I look forward to somebody from the heat community contributing v2 support before the icehouse release.

[OpenStack Infra (hudson-openstack)]

Fix proposed to branch: master
Review: https://review.openstack.org/74190

[OpenStack Infra (hudson-openstack)]

Fix proposed to branch: master
Review: https://review.openstack.org/74191

[OpenStack Infra (hudson-openstack)]

Reviewed: https://review.openstack.org/74190
Committed: https://git.openstack.org/cgit/openstack/heat/commit/?id=9b3fc1bc4ef7734d9ca32faa5798fbd940e3256d
Submitter: Jenkins
Branch: master

commit 9b3fc1bc4ef7734d9ca32faa5798fbd940e3256d
Author: Richard Lee <email address hidden>
Date: Mon Feb 17 16:11:15 2014 -0600

    Make Keystone client pluggable

    Similarly to how the engine client works, this makes it possible to
    switch out the builtin keystone client with a custom - interface
    compatible - plugin replacement.

    Co-Authored-By: Anderson Mesquita <email address hidden>
    Partial-Bug: #1274201
    Change-Id: If14ff4b34b90f46d0f468fd669dcc2fdc36c8c97

[OpenStack Infra (hudson-openstack)]

Reviewed: https://review.openstack.org/74191
Committed: https://git.openstack.org/cgit/openstack/heat/commit/?id=dc8d98dc6e9eacbd2b4f76fb423a288537356ecb
Submitter: Jenkins
Branch: master

commit dc8d98dc6e9eacbd2b4f76fb423a288537356ecb
Author: Anderson Mesquita <email address hidden>
Date: Mon Feb 17 16:11:39 2014 -0600

    Add Keystone V2 plugin

    This adds the previous Keystone V2 client to be used as a plugin by
    clouds that have not upgraded to V3 yet. This replacement also raises
    NotSupported exceptions in methods that are V3 only.

    Co-Authored-By: Richard Lee <email address hidden>
    Closes-Bug: #1274201
    Change-Id: I97d3fe7e5ff52250c699c9b470d114e53888ef15