[openstack-dev] [glance] Auth_version from 'old style' URLs in the database

Brant Knudson blk at acm.org
Mon Dec 7 17:09:54 UTC 2015


On Thu, Dec 3, 2015 at 10:24 AM, Bunting, Niall <niall.bunting at hpe.com>
wrote:

> Hi,
>
> Currently glance will use an auth_url if in the database. Eg.
> 10.0.0.8:5000/v2.0
>
> However glance currently takes the auth_version from the config
> files. Therefore this can lead to a mismatch of keystone version to be used
> between the url and the config files. This is problematic due to a
> different
> resource id being required in different version of keystone (in keystone v2
> it was /v2.0/tokens in keystone v3 it is /v3/auth/tokens).
>
> Using a v2 url and config file with keystone v3:
> 10.0.0.8:5000/v2.0/auth/tokens -- Fails to authenticate the user,
> and user can't download image.
>
> See https://bugs.launchpad.net/glance-store/+bug/1507610 for a bug report
> on this.
>
> This means that the fix proposed by
> https://review.openstack.org/#/c/238074/ parses the URL for an
> auth_version
> and then if found will use the parsed value as the auth_version rather than
> the one from the config files. Taking the url as the true source.
> Therefore the image will still work as the auth_version used by glance is
> the
> one defined in the URL meaning the correct resource id appended.
>
> Whilst discussing it with Kairat it was proposed that we ignore the
> keystone version in the URL and if it does not support the auth_version
> in the configs, then the image would fail to be downloaded. This is due to
> a
> preference to have a centralised auth_version value.
>
> I am wondering what people would prefer to do, to support the 'old style'
> urls
> and therefore parse the version from the url. Or to make the auth_version
> common and potentially break the 'old style' database entries.
>
> Thanks,
> Niall Bunting
>
>
If you want to know the version supported by the auth_url, do a GET on it
and the JSON returned will tell you what version(s) are supported. This is
preferred since parsing the value is error-prone and may not support all
deployment options (maybe somebody puts keystone v2 on /v2_old or
something). The keystoneauth library provides functions for getting the
version of the service[1].

Also, the keystoneauth library provides functions for all this stuff.
Glance shouldn't have to deal with this at all since you can just point
keystoneauth to the config section and it'll load the correct plugin and
create a session that your app can use to do its operations without
worrying about the specifics of authentication.

[1]
http://docs.openstack.org/developer/keystoneauth/api/keystoneauth1.html#module-keystoneauth1.discover

- Brant



>
> __________________________________________________________________________
> OpenStack Development Mailing List (not for usage questions)
> Unsubscribe: OpenStack-dev-request at lists.openstack.org?subject:unsubscribe
> http://lists.openstack.org/cgi-bin/mailman/listinfo/openstack-dev
>
-------------- next part --------------
An HTML attachment was scrubbed...
URL: <http://lists.openstack.org/pipermail/openstack-dev/attachments/20151207/9ad1ce8a/attachment.html>


More information about the OpenStack-dev mailing list