Open Stack

On Mon, Jan 13, 2014 at 10:38 PM, Sean Dague <sean at dague.net> wrote:

> I know we've been here before, but I want to raise this again while there
> is still time left in icehouse.
>
> I would like to propose that the Nova v3 API removes the XML payload
> entirely. It adds complexity to the Nova code, and it requires duplicating
> all our test resources, because we need to do everything onces for JSON and
> once for XML. Even worse, the dual payload strategy that nova employed
> leaked out to a lot of other projects, so they now think maintaining 2
> payloads is a good thing (which I would argue it is not).
>
>
Yes if we can establish that no one really uses it (and from the number of
bugs we've found in the V2 XML I wouldn't be surprised if large chunks of
it aren't used) or the are willing to use the JSON interface instead it'd
be worth it just from the reduced complexity in the Nova code.


> As we started talking about reducing tempest concurrency in the gate, I
> was starting to think a lot about what we could shed that would let us keep
> up a high level of testing, but bring our overall time back down. The fact
> that Nova provides an extremely wide testing surface makes this challenging.
>
>
So I think I've mentioned this before, but one additional/alternative would
be to simply  split the V2 and V3 tests into different jobs in the gate.
With most of the V2 tests ported we're planning on adding more tests to the
V3 API where there currently isn't any coverage and at least for some of
those there may be interest in V2 backports. We should also at some point
start doing scenario tests with the V3 rather than V2 API enabled.



> I think it would be a much better situation if the Nova API is a single
> payload type. The work on the jsonschema validation is also something where
> I think we could get to a fully discoverable API, which would be huge.
>

Discoverable is nice to a point but I think we need to be cautious how far
we take it as I think at least the positive tests should be written based
on the specification and not autogenerated because that will help pick up
inconsistencies we have between what we claim our API is versus what it
actually is (more automation of documentation will help reduce but I don't
think it will eliminate that problem).

Chris
-------------- next part --------------
An HTML attachment was scrubbed...
URL: <http://lists.openstack.org/pipermail/openstack-dev/attachments/20140114/d7976d99/attachment.html>