Please note: This schedule is for OpenStack Active Technical Contributors participating in the Icehouse Design Summit sessions in Hong Kong. These are working sessions to determine the roadmap of the Icehouse release and make decisions across the project. To see the full OpenStack Summit schedule, including presentations, panels and workshops, go to http://openstacksummitnovember2013.sched.org.

Sign up or log in to bookmark your favorites and sync them to your phone or calendar.

Glance [clear filter]
Tuesday, November 5

2:00pm HKT

Image state consistency between Glance and Nova
When there is a failure in Nova snapshot before uploading the image to Glance (for example failure on hypervisor capturing the disk image as a file) there is no way to notify Glance that this image is in error state nor there is a way to set it to kill. This will result on uncertainty from a client side checking image state, image state will be in queue until the call from Nova to upload which will then go to "saving" and the "active" or "killed" depending on the success of upload to store. If an error occurs before image upload request, nova cannot call update with image to upload and image will stay in "queued" state. Client will not be able to determine if this is a long running snapshot or something bad has happened. So it would be nice if there is a discussion between Glance and Nova folks on the ODS about this.

(Session proposed by Fei Long Wang)

Tuesday November 5, 2013 2:00pm - 2:40pm HKT
AWE Level 2, Room 201A

2:50pm HKT

What should happen to the v1 images api?
With the v2 api gaining maturity and ready to take center stage, what should we do about the v1 api? Deprecate it in Icehouse? Or keep it for longer, but refactor it so that we don't have to keep duplicating every feature in effectively two different codebases?

(Session proposed by Mark Washenberger)

Tuesday November 5, 2013 2:50pm - 3:30pm HKT
AWE Level 2, Room 201A

3:40pm HKT

Enhance v2 Image Sharing
Image sharing v2 was released in Grizzly. It provides a basic infrastructure for users (image consumers) to boot from images owned by other tenants (image producers). We'd like to discuss some enhancements to the feature that would support development of an image marketplace. Any such marketplace would be another service -- Glance is not in the business of maintaining user relationships, for instance -- we just want Glance image sharing to provide enough support (not too much, though!) for such a service to be built.

Etherpad for discussion: https://etherpad.openstack.org/enhancing-glance-image-sharing

BP: https://blueprints.launchpad.net/glance/+spec/enhance-v2-image-sharing

(Session proposed by Brian Rosmaita)

Tuesday November 5, 2013 3:40pm - 4:20pm HKT
AWE Level 2, Room 201A

4:40pm HKT

Enhance image location property
With multiple location feature Glance support an image has more then one backend storage location, it allow Glance using HA approach to retrieve their content from different backend when download API be required by client, and Glance also allow the image consumer access image from backend storage directly via a particular location if administrator allow glance export location metadata out to client.

Currently every image property are all belong to the image but its particular location, it caused some limitations for such useful use cases. For example, a location could has own status, under it Glance can handle location more efficiently such as 'pending_delete' for a particular location. And if we moving 'disk_format' and 'container_format' ('checksum', 'size' will be involved) properties to location level, then it could help Glance support more useful use cases, that means an image Glance owned could have different disk and/or container format, this will allow client side such as Nova consuming image more free.

I consider this change will help Glance future features' implementation also.

I'd like discuss following with team:
1. Make sure what we want to make on image location level. Which property want to add, which one want to move.
My candidate: status, disk_format, container_format, checksum and size.
2. Image location state transition diagram if we want to do it.
3. The influence for the consuming side. Client side related changing.
4. Implementation discussion.

Etherpad for discussion: https://etherpad.openstack.org/enhancing-glance-image-location-property
A related BP: https://blueprints.launchpad.net/glance/+spec/image-location-status

(Session proposed by Zhi Yan Liu)

Tuesday November 5, 2013 4:40pm - 5:20pm HKT
AWE Level 2, Room 201A

5:30pm HKT

Breaking ground with taskflow and glance
Late in the glance havana cycle there was talk about glance having features which would allow for exports/imports and a taskflow like model to accomplish this inside glance. As taskflow is a library designed for just that kind of purpose it would seem to make sense to discuss how taskflow can be used, its functionality, its plans and align it (if possible) with usage inside glance. This will avoid glance creating its own 'mini-taskflow' and let glance focus on doing image exports/imports well while letting taskflow do task running well (a separation that seems appropriate).

(Session proposed by Joshua Harlow)

Tuesday November 5, 2013 5:30pm - 6:10pm HKT
AWE Level 2, Room 201A