openstack team mailing list archive

[Dan Prince <dprince@xxxxxxxxxx>]

Eglynn pointed out some concurrency concerns in this review that I wanted to highlight:

  https://review.openstack.org/#/c/9552/

The issue is we need to provide Glance stores access to the request context. The current thought is that we'd like to modify Glance to create new Store objects for each request (thus avoiding concurrency issues). The existing Glance model creates singleton Store objects at startup. Before I go changing Glance in this regard I wanted to ask...

Does this seem reasonable?

We can still in create Store instances at startup for validation purposes. Although now that I think of it I find the log messages Glance generates from missing S3 and or Swift configs to be somewhat unnecessary. Perhaps we should rethink this startup validation as well?


Eoghan: Thanks for the detail comments on the reviews. Keep them coming.


Dan 


----- Original Message -----
> From: "Dan Prince" <dprince@xxxxxxxxxx>
> To: "OpenStack Mailing List" <openstack@xxxxxxxxxxxxxxxxxxx>
> Sent: Sunday, July 8, 2012 9:59:54 PM
> Subject: Glance/Swift tenant specific storage
> 
> 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