endpoints added with v3 are not visible with v2

[Richard Megginson]

Create an endpoint with v3::

    # openstack --os-identity-api-version 3 [--admin credentials] endpoint create ....

try to list endpoints with v2::

    # openstack --os-identity-api-version 2 [--admin credentials] endpoint list

nothing.

We are in the process of trying to convert puppet-keystone to v3 with the goal of maintaining backwards compatibility. That means, we want admins/operators not to have to change any existing workflow. This bug causes openstack endpoint list to return nothing which breaks existing workflows and backwards compatibility.

[Theodore Ilie (theoilie-ti)]

Wouldn't this not show because the v3 endpoint was posted in the v3 database and the v2 endpoint was posted in the v2 database? I don't think it would make sense for both versions to show in one command as they have different attributes (like interface; attributes may be the wrong word).

If you typed:

 # openstack --os-identity-api-version 3 [--admin credentials] endpoint list

would the endpoint not show up as usual?

[Richard Megginson (rmeggins)]

> If you typed:
>
> # openstack --os-identity-api-version 3 [--admin credentials] endpoint list
>
> would the endpoint not show up as usual?

This works fine. This command can see endpoints added with --os-identity-api-version 2 endpoint create and --os-identity-api-version 3 endpoint create.

The workaround we are using with puppet-keystone is to use --os-identity-api-version 2 endpoint create, which allows both v2 and v3 clients to do endpoint list.

But we would rather just use v3 everywhere in puppet-keystone, while preserving backwards compatibility.

[Haneef Ali (haneef)]

Isn't this asking for forward compatibility?

Create with v2, you can still use in v3 ( backward compatibility).

[Richard Megginson (rmeggins)]

> Isn't this asking for forward compatibility?

I suppose, yes. Does that make a difference?

> Create with v2, you can still use in v3 ( backward compatibility).

The problem is that the endpoint create command works differently than every other identity command. Every other identity v3 command creates resources that can be viewed/used using the v2 api. It is only endpoint create v3 that creates resources that the v2 api cannot consume.

[Jesse Pretorius (jesse-pretorius)]

I can confirm that this is a problem, and I agree that endpoints created using the v3 api really should be available via the v2 api.

[Dolph Mathews (dolph)]

This is actually by design on the Keystone side, somewhat for the reasoning mentioned in comment #1. More specifically, a v3 "endpoint" only has one URL, and an interface type. A v2 endpoint is expected to have a public URL, and may additionally have an internal URL and an admin URL.

You could easily expose v3 *public* endpoints using v2.

The design question that must be answered is regarding v3 admin and v2 internal endpoints: Given that v2 endpoints must have public URLs, how do you expose admin and internal URLs in v2? There is no guaranteed way to "match" admin and internal endpoints created with v3 to public URLs created with v3, but you could certainly guess based on other matching attributes and some assumptions (like no more than one endpoint interface per service type per region).

Definitely something we can address if we can agree on the compromises / assumptions necessary in keystone.

[OpenStack Infra (hudson-openstack)]

Reviewed: https://review.openstack.org/196943
Committed: https://git.openstack.org/cgit/stackforge/os-ansible-deployment/commit/?id=c1fdbab4de2dc69790eb95f6ad9ce9515b8ce9fa
Submitter: Jenkins
Branch: master

commit c1fdbab4de2dc69790eb95f6ad9ce9515b8ce9fa
Author: Ian Cordasco <email address hidden>
Date: Mon Jun 29 23:23:08 2015 -0500

    Upgrade the Keystone library to use v3

    In order to enable and deploy federated Keystone, we need to use version
    3 of the Keystone API and the v3 Keystone Client. This work begins that
    transition by having a set of backwards compatible library commands.

    Specifically, this commit updates the keystone library to use v3
    Keystone Client and the usage of ensure_tenant in the os_keystone tasks
    to use the v3 admin url.

    In version 3 of Keystone's Endpoints (Catalog) API each endpoint only
    has one URL and has separate interface types (public, internal, admin).
    This change updates all uses of ensure_endpoint to structure the
    endpoint data in a better way for the ensure_endpoint command in the
    keystone module. As a result, some incidents where internalurl and
    adminurl were swapped have been fixed.

    Note:
    In new deployments the endpoints will be created using the v3 API and
    will therefore not be available via the v2 API. This will be a breaking
    change to legacy CLI clients. The openstack CLI should be used instead.

    DocImpact
    Related-Bug: #1470635
    Partially-implements: blueprint keystone-federation
    Change-Id: I2cd4f505e850b4b113452abc25ee00d486b1637d

[OpenStack Infra (hudson-openstack)]

Related fix proposed to branch: kilo
Review: https://review.openstack.org/202242

[OpenStack Infra (hudson-openstack)]

Reviewed: https://review.openstack.org/202242
Committed: https://git.openstack.org/cgit/stackforge/os-ansible-deployment/commit/?id=117db2be5d26063bd21fc62170e183a7473b30c3
Submitter: Jenkins
Branch: kilo

commit 117db2be5d26063bd21fc62170e183a7473b30c3
Author: Ian Cordasco <email address hidden>
Date: Mon Jun 29 23:23:08 2015 -0500

    Upgrade the Keystone library to use v3

    In order to enable and deploy federated Keystone, we need to use version
    3 of the Keystone API and the v3 Keystone Client. This work begins that
    transition by having a set of backwards compatible library commands.

    Specifically, this commit updates the keystone library to use v3
    Keystone Client and the usage of ensure_tenant in the os_keystone tasks
    to use the v3 admin url.

    In version 3 of Keystone's Endpoints (Catalog) API each endpoint only
    has one URL and has separate interface types (public, internal, admin).
    This change updates all uses of ensure_endpoint to structure the
    endpoint data in a better way for the ensure_endpoint command in the
    keystone module. As a result, some incidents where internalurl and
    adminurl were swapped have been fixed.

    Note:
    In new deployments the endpoints will be created using the v3 API and
    will therefore not be available via the v2 API. This will be a breaking
    change to legacy CLI clients. The openstack CLI should be used instead.

    DocImpact
    Related-Bug: #1470635
    Partially-implements: blueprint keystone-federation
    Change-Id: I2cd4f505e850b4b113452abc25ee00d486b1637d
    (cherry picked from commit c1fdbab4de2dc69790eb95f6ad9ce9515b8ce9fa)

[Richard Megginson (rmeggins)]

This is not a puppet-keystone "bug". In puppet-keystone, we have worked around the issue by always using the v2 api for endpoints in the keystone_endpoint resource.

[Steve Martinelli (stevemar)]

this was fixed in commit: https://github.com/openstack/keystone/commit/4a239f23e3e599b55f6553f3b4f3290773d2ded7

[Matt Fischer (mfisch)]

This was fixed in keystone itself.