[openstack-dev] [glance] V3 Authentication for swift store

Jamie Lennox jamielennox at redhat.com
Fri Jun 19 01:49:56 UTC 2015



----- Original Message -----
> From: "stuart mclaren" <stuart.mclaren at hp.com>
> To: openstack-dev at lists.openstack.org
> Sent: Thursday, 18 June, 2015 7:06:12 PM
> Subject: Re: [openstack-dev] [glance] V3 Authentication for swift store
> 
> Hi Jamie,
> 
> Glance has another way of specifying the swift credentials for the single
> tenant store which may (?) be useful here.
> 
> In glance-swift.conf you can specify something like:
> 
> [ref1]
> user = tenant:user1
> key = key1
> auth_address = auth123 at example.com
> 
> which means that in the database 'ref1' is stored instead of the
> credentials: the location ends up looking something like:
> 
> swift+config://ref1@swift/container/object
> 
> The swift+config schema is used to indicate the real creds should be
> fetched from the config file. (This avoids having to put them in the
> database which isn't desirable and complicates password changing.)
> 
> We'd have to think about corner cases (I think --copy-from should be ok).
> 
> -Stuart
> 

<snip> 

Interesting, this actually maps really closely with one of the concepts that loading auth plugins from conf already provides. You can say

[keystone_authtoken]
auth_section = ref1
...

[ref1]
auth_plugin = password
auth_url = ... 
username = ...
...

So that you can share or separate auth. We can probably leverage something similar here.

Is this the "correct" way to configure glance? Would i be working on a deprecated section of code to make this support plugins? I can't really tell what is recommended from the code.

So the question still comes down to fix it properly or get it working. If we configure glance this way i can add user_domain_id, user_domain_name, project_domain_id, project_domain_name to the variables that are read from [ref1] and get v3 support for user/pass that way fairly easily. To move to fully loading auth_plugins we would need to either get swiftclient support for sessions or move to using the HTTP API directly. 

I'm inclined to just patch it in for now, work on getting swiftclient session support and then use that when ready. Would this be ok? 

Jamie



More information about the OpenStack-dev mailing list