Heat uses keystone_authtoken for trustee user -can't do v3 auth

[Jamie Lennox]

When delegating to a user heat uses the user that is configured in the keystone_authtoken section. This is bad behaviour and should be removed.

It means that heat is now consuming and expecting options that are deprecated in keystonemiddleware and it means that you cannot use v3 authentication to auth the trustee user. This can be seen in devstack where we are unable to update the authtoken heat configuration because it breaks the way heat loads this user.

[Dolph Mathews (dolph)]

This twisted my brain a bit at first, but if I understand this correctly: heat is reaching into auth_token's configuration options and using those instead of using it's own configuration. If so, heat should definitely not do that.

[OpenStack Infra (hudson-openstack)]

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

[OpenStack Infra (hudson-openstack)]

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

[OpenStack Infra (hudson-openstack)]

Change abandoned by Miguel Grinberg (<email address hidden>) on branch: master
Review: https://review.openstack.org/177055

[OpenStack Infra (hudson-openstack)]

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

[OpenStack Infra (hudson-openstack)]

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

commit 487a211a8a3d603ae4b77087836081037fa49c70
Author: Miguel Grinberg <email address hidden>
Date: Thu Jul 16 15:55:42 2015 -0700

    Correctly determine keystone v3 endpoint

    The auth_uri argument in the keystone_authtoken section of the
    configuration can, depending on the authentication plugin in use,
    specify the URL with or without a version. When a version is given,
    it may be v2.0 or v3. And for some plugins this setting may not even be
    used. To help reduce the coupling between heat and keystonemiddleware's
    configuration, this change adds a new "auth_uri" setting in the
    [clients_keystone] section of the configuration that can be used to define
    the unversioned keystone endpoint that heat should use. The keystone
    discovery service is used to obtain the v3 URL from this endpoint. If this
    new configuration item isn't set, then the legacy behavior that derives
    the v3 endpoint from the middleware's setting is used.

    UpgradeImpact: heat.conf [clients_keystone] auth_uri should be set
                   to the unversioned keystone endpoint for wait conditions
                   and wait handles to continue working.
    Change-Id: I57d9749bea0b5797a9fc786e8fe991bbc63301ef
    Partial-Bug: #1446918

[OpenStack Infra (hudson-openstack)]

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

commit c786a9e105e0b51a96448bb9d83fc135de81a1e6
Author: Miguel Grinberg <email address hidden>
Date: Tue Jul 28 10:57:38 2015 -0700

    Get auth_uri from [clients_keystone] section for ec2tokens

    When a specific auth_uri for ec2 isn't configured, this endpoint
    needs to be obtained from the heat specific [clients_keystone]
    section if available, and only when that is not available the
    [keystone_authtoken] setting should be used.

    Change-Id: Ie6db2845772ceee88073704bc345a6c303f396c1
    Partial-Bug: #1446918

[Steve Baker (steve-stevebaker)]

Miguel, can you give an update on what is remaining for this bug?

[OpenStack Infra (hudson-openstack)]

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

commit e43ef0ed0936b6eea08bb9d89a55547c33d2ed4a
Author: Jamie Lennox <email address hidden>
Date: Tue Apr 28 11:05:01 2015 +1000

    Use auth plugin for trustee

    Create a new config section for configuring the user that trusts are
    assigned to. This section should be configured like any other auth
    plugin however it should not provide scoping information.

    Closes-Bug: #1446918
    DocImpact: Creates a new section 'trustee' that contains the credentials
               for the user that will receive delegated roles.
    Change-Id: Idead7f505c41a55356f3670b322cbb831d442276
    Co-Authored-By: Miguel Grinberg <email address hidden>