[openstack-dev] [glance] Auth_version from 'old style' URLs in the database
Kairat Kushaev
kkushaev at mirantis.com
Fri Dec 4 12:55:45 UTC 2015
Hi,
there is another potential risk when using urls from database. Once
keystone v2 would be down there
is no way to request image using urls in database like 10.0.0.8:5000/v2.0.
<http://10.0.0.8:5000/v2.0>
The only possible option is to update db entries in glance but I am not
sure that it is correct solution.
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.
>
<http://10.0.0.8:5000/v2.0>
Is there a way to prevent this? Can't we ignore auth_url from such entries
and use the auth_address
from glance_store configuration instead?
Best regards,
Kairat Kushaev
On Thu, Dec 3, 2015 at 7:24 PM, 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
>
>
> __________________________________________________________________________
> 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/20151204/db0ec3e5/attachment.html>
More information about the OpenStack-dev
mailing list