Open Stack

Excerpts from Flavio Percoco's message of 2015-12-04 07:00:53 -0800:
> On 03/12/15 16:24 +0000, Bunting, Niall 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.
> >
>
> To clarify a bit the problem, this seems to be related only to the
> swift driver. Right?
>
> My opinion is that, whatever we do, we must not break users of this
> code.
>
> I don't believe this information should be stored in the database,
> therefore I'd prefer going with `auth_version` and write the proper
> migrations to remove this info from the DB.
>
> I don't really know why it was put there in the first place but I'll
> let folks that know this info chime in and provide some insights.
>

I agree with everything Flavio says above. These urls are not state,
they are config, which may change regardless of user action. Config
belongs in a place where operators can change it.

What may be important is to have a way to report to the operators what
urls are going to be removed before db migrations are run, so they can
be certain the config covers them all.