Open Stack

----- Original Message -----
> From: "David Kranz" <david.kranz at qrclab.com>
> To: "Dan Prince" <dprince at redhat.com>
> Sent: Monday, July 9, 2012 9:15:00 AM
> Subject: Re: [Openstack] Glance/Swift tenant specific storage
> 
> Dan, I am involved in a project (not Glance) that is doing something
> similar to this though it is at an early stage. One unresolved issue
> was
> what happens when the auth_token used to access Swift expires?

If the auth_token expired the request would fail. I'm not sure how common this scenario would be however. I suppose if you are expiring tokens very quickly then it could happen... otherwise it would take a really long Glance task to be able to hit this right?


> Unless Glance stores the user's password, and in a reversible way, how does
> it
> get a new token?


It can't. The user would have to re-submit the request to upload, download, or access the image data with a fresh token. Note: There are still some Glance tasks like delayed delete which already required a username:password (stored in a config file) to work. With Multi-tenant this would still be the case.

One thing to note: Glance isn't storing auth_tokens in this new implementation. It simply obtains the token from the incoming request and uses that to access Swift accordingly. This is actually the same thing Nova does to access Glance... so presumably any token expiration issue you'd hit with Glance-Swift integration would also potentially happen between Nova-Glance.


> This seems like a keystone use case that is not
> clear
> unless I am missing something.
> 
>   -David
> 
> On 7/8/2012 9:59 PM, Dan Prince wrote:
> > I started working on the Glance swift-tenant-specific-storage
> > blueprint last week.
> >
> > I've got a working branch in play here:
> >
> >    https://github.com/dprince/glance/commits/swift_multi_tenant3
> >
> > Some details on how I've done things so far:
> >
> >   * Update Glance so that it uses the service catalog for each user
> >   to obtain the Swift storage URL.
> >
> >   * Provide backend stores access to the context. Glance Essex
> >   doesn't give stores access to the RequestContext (auth token).
> >   We'll need this information for tenant specific storage if we
> >   want to be able to access individual swift accounts.
> >
> >   * Store images in separate containers. Swift only allows
> >   individual ACL's to be set per container... not per object. As
> >   such it appears we'll need to store each image in a separate
> >   container in order to support setting public and/or individual
> >   read/write access on each image.
> >
> >   * Set 'public' access for images in Swift.
> >
> >   * Set 'private' read and/or write access for Glance image members
> >   which have been granted access to specific images.
> >
> >   * Delayed delete (scrubber) will require an authenticated context
> >   in order to delete Swift images from the backend. Glance can
> >   either be make to grant write access to this account (for all
> >   images) or an administrative Swift account could be used to run
> >   the delayed delete operation.
> >
> >   * Maintain full support with the existing single tenant Glance
> >   swift storage scheme.
> >
> > --------
> >
> > I made some general implementation notes up on this wiki page as
> > well:
> >
> >    http://wiki.openstack.org/GlanceSwiftTenantSpecificStorage
> >
> > I'm anxious to get things up for review but before I do so I wanted
> > to ask if this implementation looks reasonable? Any thoughts or
> > feedback?
> >
> > Dan
> >
> > _______________________________________________
> > Mailing list: https://launchpad.net/~openstack
> > Post to     : openstack at lists.launchpad.net
> > Unsubscribe : https://launchpad.net/~openstack
> > More help   : https://help.launchpad.net/ListHelp
> 
>