openstack team mailing list archive

[Brian Waldon <brian.waldon@xxxxxxxxxxxxx>]

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