openstack team mailing list archive
-
openstack team
-
Mailing list archive
-
Message #04677
[GLANCE] Summary of Decisions from Summit
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