openstack team mailing list archive

[Brian Waldon <brian.waldon@xxxxxxxxxxxxx>]

The next draft of the v2 OpenStack Image API is available for review:

https://docs.google.com/document/d/1rb7ZVn0Du_5NZqUyQpqUZSmv7Qd66TMHYAtvsow7LH4/edit. 

Unfortunately, there won't be time for an official session at the summit, but feel free to start a discussion through email or by using the comment system in the doc itself. I'll also be available at the summit to discuss this in an unofficial capacity. There are still a few kinks to work out, but we're finally getting started implementing this thing. Thanks to everyone who has helped out so far!

Brian Waldon


APPENDIX A: Major Changes From Draft 3

1) Removed concept of image locations - Replication and multiple image locations are not yet well-formed. It's unclear what information/capabilities we need in the API at the moment, so I've simplified it down to just GET /images/<IMAGE_ID>/file. I would prefer to keep the public-facing API as simple as possible, so maybe this belongs in an Admin-only API. We can iterate on this for the next 6 months if we need to…

2) Replaced access_type with visibility - Rather than 'public', 'private' and 'shared', visibility can be either 'public' or 'private'. Added some explanation of how 'visibility' plays with 'owner' in the concepts section of the doc.


APPENDIX B: Outstanding issues

Some of this stuff is hard, some I just haven't put the time into figuring out yet:

1) Does it make sense to use tags, metadata, or both? I can see cases for both, but is that overkill?

2) How do we fit the existing 'copy_from' functionality in?

3) Need to properly convey link objects in json schemas

4) Need to write xsds :(

5) What link relation do we use for subcollections like tags, access, etc? http://www.iana.org/assignments/link-relations/link-relations.xml