OpenStack Essex Design Summit

It has been discussed that Glance should have clearer internal APIs that more distinctly delineate between the Python internal API and the external HTTP APIs

This session will be for brainstorming about adding extensions to Glance. We need to cover: * What exactly *is* an extension? Is an extension a truly optional component that can be switched on or off at-will? Must an extension always add to the Images API? Or can an extension change existing behaviour in a documented way? Or can an extension exist that does not modify the API in any way at all (think: transparent caching extension)? * Use cases for extensions * Possible implementation ideas for extensions * Where to put extensions? Where to document them?

Brainstorm session to flesh out a 2.0 Images API. There are a number of deficiencies in the current 1.1 Images API. Currently, the Glance API node communicates with the Glance registry and returns image metadata as HTTP headers in calls to GET /images/ and HEAD /images/. We want to split the API requests for metadata from the API requests for image data for the following reasons: 1) Unnecessary communication with registry when not requested 2) Ability to cache static image data files vs. non-static image metadata 3) Ability to have larger and more complex structured image metadata that would neither fit in HTTP headers or be easy to parse It has been proposed that the 2.0 Images API split image file and metadata into clearly delineated resource endpoints that the Glance client class would be able to navigate.

There's been a bunch of admittedly hacky code placed into the Glance API and registry servers for dealing with custom image properties. Some of the problems that are still unsolved and/or solved using pretty ugly hacks are: * The API does not allow manipulation of individual image properties * The image property is a simple key-value pair -- there is a need to have image properties have more attributes than just a key and a value, e.g. a type, owner, visibility flag, etc This session is to discuss a proposed new image properties subresource endpoint for the OpenStack Images API 2.0

A server template is a compute image plus some additional metadata (and perhaps meta-metadata) used to drive the configuration of the applications installed in the image. A server template could be used, for example, to build a server containing a pre-installed WordPress system and database, or it could be used to build a network appliance such as a VPN server or firewall. This session is to brainstorm and capture ideas for what a server template might look like, how it could be stored, and what the preliminary requirements are.

The Glance API server currently starts a wsgi server on a green thread per request. This appears to limit the processing capability of the Glance API server to a single CPU. Under heavy load this can make Glance appear un-responsive. This is especially noticeable when using SSL, where a single thread can use 100% CPU for encryption and compression processing. We propose to add multi-process support by starting up a configurable number of processes each listening on the Glance server port.