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@lists.launchpad.net Unsubscribe : https://launchpad.net/~openstack More help : https://help.launchpad.net/ListHelp
