openstack team mailing list archive

["Gabe Westmaas" <gabe.westmaas@xxxxxxxxxxxxx>]

Thanks Justin, appreciate the input!  Answers inline.

On Thursday, March 31, 2011 5:31pm, "Justin Santa Barbara" <justin@xxxxxxxxxxxx> said:

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

So the XML is generated based on the json, but it goes through an additional transformation so just checking the XML does not ensure that the json is correct.

Good point about an example, I should have provided one!  Below is the output for a JSON and XML request on the same resource (/servers/<id>).  Things are mostly correct until you get down to the IP address and metadata level.

{"server": 
  {"status": "active", 
   "hostId": "84fd63700cb981fed0d55e7a7eca3b25d111477b5b67e70efcf39b93", 
   "addresses": {"public": [], "private": ["172.19.1.2"]}, 
   "name": "metaserver", 
   "flavorId": "m1.tiny", 
   "imageId": "1", 
   "id": 6, 
   "metadata": {"data1": "value1"}
  }
}

<server flavorId="m1.tiny" hostId="84fd63700cb981fed0d55e7a7eca3b25d111477b5b67e70efcf39b93" id="6" imageId="1" name="metaserver" status="active">
    <addresses>
        <public/>
        <private>
            <item>
                172.19.1.2
            </item>
        </private>
    </addresses>
    <metadata>
        <data1>
            value1
        </data1>
    </metadata>
</server>

Correct XML would be:
<server flavorId="m1.tiny" hostId="84fd63700cb981fed0d55e7a7eca3b25d111477b5b67e70efcf39b93" id="6" imageId="1" name="metaserver" status="active">
    <addresses>
        <public/>
        <private>
            <ip addr="10.176.42.16"/>
        </private>
    </addresses>
    <metadata>
        <meta key="data1">value1</meta>
    </metadata>
</server>


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

As far as 1.1 goes, I think the backend features that we were waiting on are there now, but as we all had a bunch of late merges, we didn't have the time to implement the API side before feature freeze.  For 1.0 missing features...we honestly didn't look at those two (shared ips and backup scheduling) because we didn't feel they added a ton of value above above what was coming in the 1.1 spec. So I'm not sure if the necessary backends are there, though I would guess no.  Someone else chime in here if that's wrong!

> 
> 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
> re-numberings.
> 
>> One point I would like to ask about is how important is XML to the 1.0
> implementation?
> 
> 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)
> 
> 
> Justin
>