Hey all, Below, please find a summary of the decisions/actions that came out of the design summit last week. Feedback and comments are most welcome.
1) Release Cycle Glance will follow a similar cadence to Nova and Keystone during the Essex release cycle, with the exception that Glance will release its first release candidate one week earlier than Nova to increase stability during the final weeks of the release cycle. 2) Major Changes to the OpenStack Images API in Essex We will be proposing an OpenStack Images 2.0 API in the next week or so and opening up the proposal for discussion and comments on the mailing list. The major changes/improvements to the API will include: * Removal of the HTTP header-based communication of image metadata * Overhaul of the way custom image properties are get/set * Dynamic typed image attributes with introspection/discovery by client * Separation of the image file resource from metadata about the image * Better use of HTTP Cache headers Be on the look out for a mailing list post with the subject [GLANCE] Request for Comment -- Proposed OpenStack Images 2.0 API 3) Improvements to Glance's Implementation of the OpenStack Images API There were lots of good discussions around how to make Glance's implementation better, faster, stronger. Some new things you should expect to see coming in Essex: * Solid internal Python API Currently, the internal Python API is inconsistent and needs to be cleaned up to provide a consistent interface to the public-facing protocol controllers. This refactoring/cleanup is necessary before Glance can begin communicating over more than just HTTP (think: AMQP) * Having a streamlined, dependency-free client package Currently the Glance client Python package has dependencies on way too many packages that it really doesn't need. This will be cleaned up in Essex. * Caching The current image cache in Glance will be made a true optional extension, and we will look into adding some additional functionality that was brought up at the summit around using BitTorrent to spread cached image files to other Glance streaming servers. Speaking of streaming servers... * Split of the unified API server <--> client communication There are a number of inefficiencies involved with the current client -> API server communication that we aim to eliminate by allowing the Glance client to directly communicate with one or more Glance Registry servers, bypassing the Glance image streaming servers when image files are not needed. * Performance and throughput We will be adding code from Swift and contributors from HP that increase the throughput of Glance's streaming servers considerably. Cheers, and please feel free to provide additions and feedback if I missed or mischaracterized anything above. -jay _______________________________________________ Mailing list: https://launchpad.net/~openstack Post to : openstack@lists.launchpad.net Unsubscribe : https://launchpad.net/~openstack More help : https://help.launchpad.net/ListHelp
