openstack team mailing list archive

[Jay Pipes <jaypipes@xxxxxxxxx>]

On Mon, Feb 14, 2011 at 4:27 PM, Jorge Williams
<jorge.williams@xxxxxxxxxxxxx> wrote:
> On Feb 14, 2011, at 3:08 PM, Jay Pipes wrote:
> 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.

Cool, thanks Jorge! :)

>> 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.

Hmm, I suppose that's possible, too.  I'd prefer a unique field that
has version information, but either could work.

Another field that could be nice is "author" or "authors" to allow the
developers or developer company/organization to be listed?

>> 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.

Cool :)

>> 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.

Gotcha. Will do :)

Cheers,
jay