Open Stack

On Feb 14, 2011, at 3:08 PM, Jay Pipes wrote:

> The reason I haven't responded yet is because it's difficult for me to:
> 
> diff -u some.pdf other.pdf
> 
> In all seriousness, the wiki spec page says this about the differences
> in the 1.1 OpenStack API:
> 


I'll work with Anne to make the source documents available to you guys so you can do a diff etc.  Give me a couple of days to get this working, existing docs are built into the implementation, this is a nice thing because our unit tests use the samples from the docs to make sure they're always correct...anyway now  I need to separate these out.


> ==start wiki==
> 
> OS API 1.1 Features
> 
> IPv6
> 
> Extensions
> 
> Migrate to OpenStack namespace
> 
> ==end wiki==
> 
> There's just not much detail to go on. I had to go through the PDF to
> see what the proposed changes to the CS 1.0 API looked like.
> 
> After looking at the PDF, I have a couple suggestions for improvement,
> but overall things look good :)
> 
> 1) Give extensions a way to version themselves. Currently, the main
> fields in the API response to GET /extensions looks like this:
> 
> {
> "extensions" : [
> {
> "name" : "Public Image Extension",
> "namespace" : "http://docs.rackspacecloud.com/servers/api/ext/pie/v1.0",
> "alias" : "RS-PIE",
> "updated" : "2011-01-22T13:25:27-06:00",
> "description" : "Adds the capability to share an image with other users.",
> "links" : [
> {
> "rel" : "describedby",
> "type" : "application/pdf",
> "href" : "http://docs.rackspacecloud.com/servers/api/ext/cs-pie-20111111.pdf"
> },
> {
> "rel" : "describedby",
> "type" : "application/vnd.sun.wadl+xml",
> "href" : "http://docs.rackspacecloud.com/servers/api/ext/cs-pie.wadl"
> }
> ]
> }, ... ]}
> 
> I would suggest adding a "version" field to the extension resource
> definition so that extension developers will have a way of identifying
> the version of their extension the OpenStack deployment has installed.

Do we want to deal with extension versions?  If you need to version your extension because it's not backwards compatible simply create a new extension and append a version number to it. So RS-CBS and RS-CBS2, etc. This is how things work with OpenGL which served as a reference for our extension mechanism.

> 
> 2) I would suggest leaving the "links" collection off of the main
> result returned by GET /extensions and instead only returned the
> "links" collection when a specific extension is queried with a call to
> GET /extensions/<ALIAS>. You could even mimick the rest of the CS API
> and do a GET /extensions/detail that could return those fields?

I like this idea.

> 
> 3) IPv6 stuff in the PDF looked good as far as I could tell. Mostly, I
> was looking at the examples on pages 29 and 30. Was there a specific
> section that spoke to IPv6 changes; I could not find one.
> 

I'm working to flesh this out a bit. Also I've gotten a bunch of comments on eitherpad (http://etherpad.openstack.org/osapi1-1), which I'm incorporating into the spec.  Expect more comments on eitherpad, and a new revision of the spec soon --  as well as access to the source :-).  In the meantime keep comments coming.

Thanks,

jOrGe W.









Confidentiality Notice: This e-mail message (including any attached or
embedded documents) is intended for the exclusive and confidential use of the
individual or entity to which this message is addressed, and unless otherwise
expressly indicated, is confidential and privileged information of Rackspace. 
Any dissemination, distribution or copying of the enclosed material is prohibited.
If you receive this transmission in error, please notify us immediately by e-mail
at abuse at rackspace.com, and delete the original message. 
Your cooperation is appreciated.