Open Stack

On 01/21/2014 10:22 AM, Mark McLoughlin wrote:
> On Tue, 2014-01-14 at 09:29 -0500, Doug Hellmann wrote:
> 
>> I would like to see an affirmative statement from the TC like "We are
>> planning to start dropping XML support in APIs during Juno in order to
>> focus our limited development resources" (or a later release, or "we are
>> going to keep doing XML whether we like it or not") posted to the mailing
>> list for feedback, rather than the open-ended "what do you want" questions
>> we've been posing.
> 
> I'm generally against us closing doors and saying "we never want XML
> support, no matter how much work you're willing to do on it". A ban on
> XML or a "JSON is the one true representation" statement isn't what
> we're trying to achieve.
> 
> We want:
> 
>   1) Clear guidance to users that XML support is known to be very week 
>      and, due to lack of interest in developing and maintaining it, XML 
>      support could get worse in future releases. I'm thinking XML
>      support off by default, warnings in documentation, notices in
>      release notes, etc.

I think we have to make a statement about features in the projects need
some guaranteed level of support and interest. This same rationale is
why driver 3rd party testing was brought forward to prevent the
situation where we've had in the past that vendor shows up, drops code
in tree, doesn't bother to maintain it, it breaks for users, and the
overall project looks bad.

Much better to have less features that are better supported, than more
features that are not.

>   2) An understanding that because of the lack of active maintenance of 
>      XML support, authors of new features can choose to regress XML 
>      support. Semi-working XML support can't be allowed to hold up 
>      progress.

So to be clear, I'm not actually making that statement. I think we've
given a contract to our users on existing APIs, regressing those isn't
user friendly, and something I don't agree with.

So Nova v2 - you want to add a feature or fix a bug, it needs both
payloads.

What this is really about is new things, like Nova v3.

Going forward - new major versions of API not yet declared stable, we
encourage projects to only support JSON, and not XML, by making that
policy that stable JSON interface is what's required out of our web
services.

If a project really wants to support an XML payload, I think it should
be a requirement that the python client library for that service has
full JSON / XML parity for all calls, so that the official SDK from
OpenStack for services at those API levels works either way.

Basically we keep assuming having all this extra surface is cheap, and
it isn't. There are real costs here in complexity, man power, and test
throughput that make us a worse project by having to support more of
these features.

It is also extremely notable that when we look at the two big
proprietary public clouds today (AWS and GCE), they don't bother with
the idea of multiple data formats. One uses XML, the other uses JSON,
end of story. This legacy of doing both is just that, legacy, and we
should really push out of legacy and towards a cleaner future.

	-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: 547 bytes
Desc: OpenPGP digital signature
URL: <http://lists.openstack.org/pipermail/openstack-tc/attachments/20140121/0632a1e7/attachment.pgp>