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. __________________________________________________________________________ OpenStack Development Mailing List (not for usage questions) Unsubscribe: [email protected]?subject:unsubscribe http://lists.openstack.org/cgi-bin/mailman/listinfo/openstack-dev
