Merge lp://qastaging/~johannes.erdfelt/nova/lp844910 into lp://qastaging/~hudson-openstack/nova/trunk

Personally, I feel like these new content types are just aliases to their simpler counterparts. I don't really think it is necessary to map them individually for (de)serialization. Did you think about writing a simple middleware that just simplifies the content types?

I had thought about that, but if you alias the values, then the content-type returned won't necessarily match what is requested in the accept header.

Being middleware, you could remember that you aliased the value in the request and set it back in the response.

True, but the code would be relatively complicated. Much of the code in nova/api/openstack/wsgi.py deals with determining the best match for the accept header. This isn't trivial since content types can be weighted.

To handle the case of "application/vnd.openstack.compute+xml; q=0.2, application/xml; q=0.8" would require some fairly sophisticated code to parse out the accept, choose the best match, possibly replace/remove it from the accept header and then possibly replace the content-type on the response path.

It would duplicate much of the existing code.

The proposed branch is extremely straight forward and has no tricky code in it. I still think it's the better option.

> True, but the code would be relatively complicated. Much of the code in
> nova/api/openstack/wsgi.py deals with determining the best match for the
> accept header. This isn't trivial since content types can be weighted.
>
> To handle the case of "application/vnd.openstack.compute+xml; q=0.2,
> application/xml; q=0.8" would require some fairly sophisticated code to parse
> out the accept, choose the best match, possibly replace/remove it from the
> accept header and then possibly replace the content-type on the response path.

Sophisticated code that's actually already written :)

http://docs.webob.org/en/latest/reference.html#accept-headers

-jay

The sophisticated code I meant was the code to wrap up the webob best match code with code to modify the Accept header.

The webob code makes matching against the Accept header easy, but not modifying it. That's the sophisticated part.

OK, I don't really see why you would need to modify the Accept header at all (is that even advisable/legal?)

In any case, my remark is not consequential to this patch being good, which it is ;)

I've made changes to simplify the code a little bit and fix a bug that snuck during a merge. The vendor types will be mapped to the standard types when the code goes to serialize or deserialize. This simplifies the code while minimizing the changes to all of the other code that handles XML serialization.

I also added a couple of more tests and a missing copyright.

This is great, Johannes.

This looks good.