middleware provides no way to know if a catalog is v2 or v3

[Jamie Lennox]

auth_token provides X_SERVICE_CATALOG as a header however it doesn't provide the root catalog element. So on v2 we get something like:

[{'endpoints': [{'adminURL': 'http://127.0.0.1:8776/v1/64b6f3fbcc53435e8a60fcf89bb6617a',
    'internalURL': 'http://127.0.0.1:8776/v1/64b6f3fbcc53435e8a60fcf89bb6617a',
    'publicURL': 'http://127.0.0.1:8776/v1/64b6f3fbcc53435e8a60fcf89bb6617a',
    'region': 'regionOne'}],
  'endpoints_links': [],
  'name': 'volume',
  'type': 'volume'},
 {'endpoints': [{'adminURL': 'http://127.0.0.1:9292/v1',
    'internalURL': 'http://127.0.0.1:9292/v1',
    'publicURL': 'http://127.0.0.1:9292/v1',
    'region': 'regionOne'}],
  'endpoints_links': [],
  'name': 'glance',
  'type': 'image'},
 {'endpoints': [{'adminURL': 'http://127.0.0.1:8774/v1.1/64b6f3fbcc53435e8a60fcf89bb6617a',
    'internalURL': 'http://127.0.0.1:8774/v1.1/64b6f3fbcc53435e8a60fcf89bb6617a',
    'publicURL': 'http://127.0.0.1:8774/v1.1/64b6f3fbcc53435e8a60fcf89bb6617a',
    'region': 'regionOne'}],
  'endpoints_links': [],
  'name': 'nova',
  'type': 'compute'},
 {'endpoints': [{'adminURL': 'http://127.0.0.1:35357/v2.0',
    'internalURL': 'http://127.0.0.1:35357/v2.0',
    'publicURL': 'http://127.0.0.1:5000/v2.0',
    'region': 'RegionOne'}],
  'endpoints_links': [],
  'name': 'keystone',
  'type': 'identity'}]

and on v3:

[{
                        'endpoints': [{
                            'url':
                            'http://public.com:8776/v1/None',
                            'region': 'RegionOne',
                            'interface': 'public'
                        }, {
                            'url':
                            'http://internal:8776/v1/None',
                            'region': 'RegionOne',
                            'interface': 'internal'
                        }, {
                            'url':
                            'http://admin:8776/v1/None',
                            'region': 'RegionOne',
                            'interface': 'admin'
                        }],
                        'type': 'volume'
                    }, {
                        'endpoints': [{
                            'url': 'http://public.com:9292/v1',
                            'region': 'RegionOne',
                            'interface': 'public'
                        }, {
                            'url': 'http://internal:9292/v1',
                            'region': 'RegionOne',
                            'interface': 'internal'
                        }, {
                            'url': 'http://admin:9292/v1',
                            'region': 'RegionOne',
                            'interface': 'admin'
                        }],
                        'type': 'image'
                    }, {
                        'endpoints': [{
                            'url':
                            'http://public.com:8774/v1.1/None',
                            'region': 'RegionOne',
                            'interface': 'public'
                        }, {
                            'url':
                            'http://internal:8774/v1.1/None',
                            'region': 'RegionOne',
                            'interface': 'internal'
                        }, {
                            'url':
                            'http://admin:8774/v1.1/None',
                            'region': 'RegionOne',
                            'interface': 'admin'
                        }],
                        'type': 'compute'
                    }, {
                        'endpoints': [{
                            'url': 'http://public.com:8773/services/Cloud',
                            'region': 'RegionOne',
                            'interface': 'public'
                        }, {
                            'url': 'http://internal:8773/services/Cloud',
                            'region': 'RegionOne',
                            'interface': 'internal'
                        }, {
                            'url': 'http://admin:8773/services/Admin',
                            'region': 'RegionOne',
                            'interface': 'admin'
                        }],
                        'type': 'ec2'
                    }, {
                        'endpoints': [{
                            'url': 'http://public.com:5000/v3',
                            'region': 'RegionOne',
                            'interface': 'public'
                        }, {
                            'url': 'http://internal:5000/v3',
                            'region': 'RegionOne',
                            'interface': 'internal'
                        }, {
                            'url': 'http://admin:35357/v3',
                            'region': 'RegionOne',
                            'interface': 'admin'
                        }],
                        'type': 'identity'
                    }]

now we *can* look in the list elements for a 'url' element but that's a bad way to figure this out. Also the ServiceCatalog.factory() function tests for v2 or v3 based on the elements of the token NOT on the elements of the catalog.

We need to figure out a way to communicate this to a server either with a
 - header with the token type v2 or v3
 - header with the full token
 - something else

[Dolph Mathews (dolph)]

A stop-gap solution could be to try to provide services with a "v2 catalog" either way, but there are some caveats for deployments taking advantage of the extra flexibility afforded by v3's catalog structure. The three that come to mind:

- A public interface is not guaranteed to exist in v3 as it is in v2
- Endpoints on distinct interfaces can't be lumped back together as they are in v2
- It's possible to define your own interface in v3 that cannot be represented in v2

[Dolph Mathews (dolph)]

The opposite approach (always providing a "v3 catalog") would take more work, but a v2 catalog can be easily represented as a v3 catalog.

[Jamie Lennox (jamielennox)]

Ideally we would avoid having vX specific data progressing through the middleware. However coming up with some new independent format is no better than just using the v3 catalog.

I'm hoping that the longer term solution is that middleware will provide a Session object and everyone use that but we apparently need to support the headers only case.

[Dolph Mathews (dolph)]

Jamie: Completely agree!

[Jamie Lennox (jamielennox)]

The short term solution to close this bug and make things usable for people is just to make the catalog given by X-Service-Catalog always be a v2 catalog.

Later we can determine a way to provide a common header, but in general having a big dump of JSON in a header is a bad idea anyway.

[OpenStack Infra (hudson-openstack)]

Reviewed: https://review.openstack.org/89458
Committed: https://git.openstack.org/cgit/openstack/python-keystoneclient/commit/?id=c1c5669d0c95ca43788abcb3eda07fd3bccec73f
Submitter: Jenkins
Branch: master

commit c1c5669d0c95ca43788abcb3eda07fd3bccec73f
Author: Jamie Lennox <email address hidden>
Date: Tue Apr 22 12:17:42 2014 +1000

    Make auth_token return a V2 Catalog

    As there is no way to distinguish a v2 or v3 catalog from the headers
    provided to an application we will for the meantime always return a v2
    catalog. This should not cause any issues as the full token data is not
    provided to the service so there is no-one that will get caught out by a
    v2/v3 mix, and anyone that is already supporting the v3 catalog format
    will have to support the v2 catalog format as well so it will continue
    to work.

    Change-Id: Ic9b38e0ba4682b47ae295bd3f89bac59ef7437cf
    Closes-Bug: #1302970