Obsolete:GlanceSwiftTenantSpecificStorage

= Glance Tenant Specific Storage =

Goal
Store image data in the authenticated user's swift account.

Existing behaviour (as of Essex)
Currently Glance swift stores public and private images in a single swift account. The username and password credentials for this account are stored both in the Glance API config file and in the 'location' field within the database. This password is duplicated in the 'location' field for every single image within the database. A typical location URL which is stored in the database when using single tenant Swift storage may look like this:

`swift+http://user:pass@authurl.com/container/obj-id`

Glance manages access to public images and per user image membership internally. Access to the backend swift store always requires a username:password which is typically obtained from the 'location' URI and/or the Glance config file.

It is also important to note that Glance currently stores images within a single Swift container.

New behavior
When using Glance with swift in multi-tenant storage mode the username/password for the Swift account is not stored in the database. The auth token for the authenticated user is used to access swift images from the backend store.

A typical 'location' URI in the Glance database might look like this when using multi-tenant storage:

`swift+https://storage_url.com/container/obj-id`

Note: In this form the storage_url is used instead of the auth_url which is used in the single tenant format.

Glance will need to set permissions on individual images in the backend Swift store to allow either public or per member/tenant access.

Implementation changes:


 * 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.

-

To be done:


 * Config options to select a specific service_type and/or endpoint URL from the service catalog for the swiftclient connections. Swiftclient doesn't support these options yet so we'll need to add them there first... These options would be useful if a deployer wanted to have two installations of Swift (one for Glance, and one for General use). It might also be uesful to use an alternate internal swift endpoint by default.