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

Flavio Percoco flavio at redhat.com
Fri Dec 4 15:00:53 UTC 2015


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.                                                                                                                                                   
                                                                                                                                                                                                                    
Cheers,                                                                                                                                                                                                             
Flavio 

>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

-- 
@flaper87
Flavio Percoco



More information about the OpenStack-dev mailing list