openstack team mailing list archive

[stuart.mclaren@xxxxxx]

Hi Brian,

Thanks for circulating this -- it looks more efficient for both
data and metadata.

A couple of quick queries...

1) Caching

If your image is located in swift you can choose to go directly to swift
to fetch the image.  Will this image also now be automatically cached
on the glance server, so next time around when you query the server
you will be given a local filesystem location?

2) Access control

If the user can go directly to Swift to access an image does that
mean they can bypass Glance and directly delete that image? (Putting
meta-data/data out of sync.)

Thanks,

-Stuart

On Mon, 30 Apr 2012, Brian Waldon wrote:

> I've been thinking about how we can optimize the architecture of Glance while providing more flexibility to the consumer of the API. Some of the goals I have are:
>
> 1) Minimize request overhead - It feels wasteful to duplicate requests from the glance-api to the glance-registry.
>
> 2) Divide responsibilities clearly - The glance-api server is responsible for talking to keystone, the glance-registry, and several backend stores, while the glance-registry server only talks to the database. This feels like we're overloading glance-api with extra responsibilities.
>
> 3) Allow a user to stream image data directly from the backend - if a user is trusted (such as Nova), Glance shouldn't require streaming images through its servers.
>
> Here's how Glance is currently set up:
>
> A typical deployment is comprised of one to many glance-api servers and one to many glance-registry servers. The glance-api servers accept HTTP requests directly from the client, authenticate/authorize them, then speak to image storage backends and glance-registry servers. The glance-registry servers listen for HTTP requests from the glance-api servers (not end-users) and in turn make requests to a database.
>
> And this is my proposed architecture:
>
> One to many glance-api servers authenticate (via Keystone) end-user requests and talk directly to the database. These servers farm out image streaming to a glance-stream server. The responsibility of a glance-stream server is to stream image data from backends while masking credentials and providing caching. Alternatively, a user should be able to stream directly from a backend (depending on trust level) using a link obtained from a glance-api request and bypass the glance-stream server altogether.
>
> Please send any thoughts my way!
>
> Brian
>
>
> _______________________________________________
> Mailing list: https://launchpad.net/~openstack
> Post to     : openstack@xxxxxxxxxxxxxxxxxxx
> Unsubscribe : https://launchpad.net/~openstack
> More help   : https://help.launchpad.net/ListHelp