<div dir="ltr"><div><div><div><div>Hi,<br></div>there is another potential risk when using urls from database. Once keystone v2 would be down there<br>is no way to request image using urls in database like<a href="http://10.0.0.8:5000/v2.0" rel="noreferrer" target="_blank"> 10.0.0.8:5000/v2.0.</a><br></div>The only possible option is to update db entries in glance but I am not sure that it is correct solution.<br></div></div><div><br><blockquote style="margin:0px 0px 0px 0.8ex;border-left:1px solid rgb(204,204,204);padding-left:1ex" class="gmail_quote">I am wondering what people would prefer to do, to support the 'old style' urls<br>
and therefore parse the version from the url. Or to make the auth_version<br>
common and potentially break the 'old style' database entries.<br></blockquote></div><div><div><div><a href="http://10.0.0.8:5000/v2.0" rel="noreferrer" target="_blank"></a><div><div><div><div><div class="gmail_extra"><br></div><div class="gmail_extra">Is there a way to prevent this? Can't we ignore auth_url from such entries and use the auth_address<br>from glance_store configuration instead?<br></div><div class="gmail_extra"><br clear="all"><div><div class="gmail_signature"><div dir="ltr"><div><div dir="ltr">Best regards,<div>Kairat Kushaev</div></div></div></div></div></div>
<br><div class="gmail_quote">On Thu, Dec 3, 2015 at 7:24 PM, Bunting, Niall <span dir="ltr"><<a href="mailto:niall.bunting@hpe.com" target="_blank">niall.bunting@hpe.com</a>></span> wrote:<br><blockquote class="gmail_quote" style="margin:0px 0px 0px 0.8ex;border-left:1px solid rgb(204,204,204);padding-left:1ex">Hi,<br>
<br>
Currently glance will use an auth_url if in the database. Eg. <a href="http://10.0.0.8:5000/v2.0" rel="noreferrer" target="_blank">10.0.0.8:5000/v2.0</a><br>
<br>
However glance currently takes the auth_version from the config<br>
files. Therefore this can lead to a mismatch of keystone version to be used<br>
between the url and the config files. This is problematic due to a different<br>
resource id being required in different version of keystone (in keystone v2<br>
it was /v2.0/tokens in keystone v3 it is /v3/auth/tokens).<br>
<br>
Using a v2 url and config file with keystone v3:<br>
<a href="http://10.0.0.8:5000/v2.0/auth/tokens" rel="noreferrer" target="_blank">10.0.0.8:5000/v2.0/auth/tokens</a> -- Fails to authenticate the user,<br>
and user can't download image.<br>
<br>
See <a href="https://bugs.launchpad.net/glance-store/+bug/1507610" rel="noreferrer" target="_blank">https://bugs.launchpad.net/glance-store/+bug/1507610</a> for a bug report<br>
on this.<br>
<br>
This means that the fix proposed by<br>
<a href="https://review.openstack.org/#/c/238074/" rel="noreferrer" target="_blank">https://review.openstack.org/#/c/238074/</a> parses the URL for an auth_version<br>
and then if found will use the parsed value as the auth_version rather than<br>
the one from the config files. Taking the url as the true source.<br>
Therefore the image will still work as the auth_version used by glance is the<br>
one defined in the URL meaning the correct resource id appended.<br>
<br>
Whilst discussing it with Kairat it was proposed that we ignore the<br>
keystone version in the URL and if it does not support the auth_version<br>
in the configs, then the image would fail to be downloaded. This is due to a<br>
preference to have a centralised auth_version value.<br>
<br>
I am wondering what people would prefer to do, to support the 'old style' urls<br>
and therefore parse the version from the url. Or to make the auth_version<br>
common and potentially break the 'old style' database entries.<br>
<br>
Thanks,<br>
Niall Bunting<br>
<br>
<br>
__________________________________________________________________________<br>
OpenStack Development Mailing List (not for usage questions)<br>
Unsubscribe: <a href="http://OpenStack-dev-request@lists.openstack.org?subject:unsubscribe" rel="noreferrer" target="_blank">OpenStack-dev-request@lists.openstack.org?subject:unsubscribe</a><br>
<a href="http://lists.openstack.org/cgi-bin/mailman/listinfo/openstack-dev" rel="noreferrer" target="_blank">http://lists.openstack.org/cgi-bin/mailman/listinfo/openstack-dev</a><br>
</blockquote></div><br></div></div></div></div></div></div></div></div></div>