Open Stack

On 01/14/2014 05:17 AM, Christopher Yeoh wrote:
> On Mon, Jan 13, 2014 at 10:38 PM, Sean Dague <sean at dague.net
> <mailto: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.

This skirts the run time issue, but using twice as many resources. It
doesn't however address the fact that real effort goes into maintaining
and reviewing those clients. Or the review on the Nova side to get these
things in. Or the double documentation duties. Or the fact that it
inhibits certain things in JSON because they wouldn't be XML friendly.
Or the extra code that we need to carry around to handle bad XML insertion.

There is a real cost of our dual data payload strategy. A cost in real
people that means we aren't doing other things, or doing other things
better.

The folks working on keeping XML alive aren't doing it because they have
a dramatic passion for XML and wouldn't be contributing to the project
otherwise, so I think we'd be able to cover far more important parts of
the project if we dropped this load.

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

I don't want discoverability for Tempest (not on the positive side), I
100% believe that we should remain explicit on function testing.

I want discoverability for Users and SDKs. I want user toolkits that
work with Nova to have a fully discoverable way to work with our API. As
I think that would be a *great* API for our users, and would make life
dramatically simpler for our SDK ecosystem.

	-Sean

-- 
Sean Dague
Samsung Research America
sean at dague.net / sean.dague at samsung.com
http://dague.net

-------------- next part --------------
A non-text attachment was scrubbed...
Name: signature.asc
Type: application/pgp-signature
Size: 482 bytes
Desc: OpenPGP digital signature
URL: <http://lists.openstack.org/pipermail/openstack-dev/attachments/20140114/bec841cc/attachment.pgp>