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
_______________________________________________
Mailing list: https://launchpad.net/~openstack
Post to : openstack@lists.launchpad.net
Unsubscribe : https://launchpad.net/~openstack
More help : https://help.launchpad.net/ListHelp
