← Back to team overview

openstack team mailing list archive

Re: Proposal to defer existing OS API v1.1 to Diablo, for greater stability in Cactus


I think there are a few distinct issues:

1) XML support.  I was thinking that most XML issues would also be issues in
the JSON, so validating the XML will also serve as validating the JSON.  I'd
appreciate an example here, but I agree in general that focusing on JSON is
acceptable - as long as its not just that we don't see the problems in JSON
because we're not validating it as thoroughly.

2) Missing features.  I don't think of this as an API issue, unless these
are supported features which we simply aren't exposing.  My understanding is
that it's the underlying support that's holding this back, not the API

3) The v1.1 schema changes.  To be honest, I'm still confused here.  I think
you want to maximize compatibility with Cloud Servers v1.0, so it sounds
like you would also want a minimal v1.1 that was just the bare minimum
additional features to support additional features in nova (e.g.
changePassword action)  I don't really understand where the 'nice to have'
(e.g. atom links) changes came from in that case.  I think everyone would
support a minimal set of changes to the CloudServers v1.0 API; even if
people would rather have their own OpenStack API long-term, supporting the
two existing cloud APIs is an obvious win.

> Given this, what makes the most sense to me is to focus on stability for
version 1.0 API excluding XML support.  The bindings that are out there have
strong support for the JSON data formats in v1.0.  As suggested, I think we
call the current mostly implemented 1.1 API experimental so as to give
access to any features that we need that are only in 1.1.

I think v1.0 is a good API, and has the advantage that a lot of existing
clients work with it.  I would personally like XML support to be in there,
but I understand that we need to make sacrifices, so accept that the focus
should be on JSON in v1.0.

I think calling v1.1 experimental and discussing it at the Design Summit is
the right thing to do.  If you need to extend v1.0 (e.g. to support
restartServer in "v1.0"), then I think you can make the call on

> One point I would like to ask about is how important is XML to the 1.0

I personally would like to see XML support shipped, even if marked
experimental and not 100%.  I had thought that getting the XML right would
mean we got the JSON right also, and it's easier to test the XML.  However,
I totally agree that JSON should be our top priority.  Given the time
situation, I think XML work should only be done to help the JSON (e.g.
adding namespaces to the XML lets us do a schema validation, which
indirectly helps us check the JSON => yes.  Fixing XML output where the JSON
output is already valid => not a priority)


Follow ups