Open Stack

On 02/24/2014 08:16 PM, Christopher Yeoh wrote:
> On Mon, 24 Feb 2014 16:20:12 -0800
> Dan Smith <dms at danplanet.com> wrote:
>>> So the deprecation message in the patch says:
>>>
>>>        LOG.warning(_('XML support has been deprecated and will be
>>>          removed in the Juno release.'))
>>>
>>> perhaps that should be changed :-)
>>
>> Maybe, but I think we can continue with the plan to rip it out in
>> Juno. In the past when we've asked, there has been an overwhelming
>> amount of "meh" regarding removing it. We've considered it several
>> times, and we've now drawn a line in the sand. Personally, I'm fine
>> with doing this, and I think the support from the core team that +A'd
>> the heck out of it probably means that there is wide support for it.
> 
> Sure, I was using it as an example of where we have been willing to use
> a fixed deprecation schedule for the API. 

Well, I got a little carried away when I wrote that message.  I think we
should change it.  I don't think it's a responsible thing to do to
remove it unless we do another good round of assessing what the impact
would be and then only removing it when the impact is very minimal.

I'd really like some help from the public cloud providers to get some
insight into the percentage of their users that use XML.  We likely have
some work to do in Nova to make it easier to collect this data.

> If we look at the Havana
> user survey I think the results say:
> 
> http://www.slideshare.net/openstack/havana-survey-resultsfinal-19312081
> 
> JSON: 150
> XML: 62
> Both: 33
> 
> So thats around 40% of those surveyed who would be affected. 
> So if we can draw a line in the sand based on those sorts of numbers,
> why is it impossible to do it for the V2 API as a whole? Albeit I
> think more than one cycle would be needed.
> 

Sadly, I think those results are near useless.  For example:

 - it doesn't differentiate based on the type of responder.  Is it
   deployers saying they deploy the XML API (they don't have a choice).
   There is no way to know about cloud usage here.

 - is there possible confusion with EC2?  (EC2 is XML)

However, getting good data here *is* important.

Also note that none of the major SDKs use XML.  In addition to our own
client libraries, the following only use JSON:

Apache jclouds (Java)
openstack.net (C#)
pkgcloud (node.js)
php-opencloud (PHP)
Fog (Ruby)

>>> So either we can't fix them or in cases where we preserve backwards
>>> compatibility we end up with dual maintenance cost (our test load
>>> still doubles), but often having to be implemented in a way which
>>> costs us more in terms of readability because the code becomes
>>> spaghetti.
>>
>> I think it can be done without it turning into a mess. Non-trivial for
>> sure, but not impossible. And if not, I still expect most users would
>> prefer stability over purity.
> 
> We're not choosing between stability of purity though. As I've argued
> elsewhere its not about 'purity', its about usability. And say we do
> manage to do it without it turning into complete mess, we still have
> the dual maintenance cost which seems to be the primary concern about
> having both the V2 and V3 API released.
> 
> By supporting backwards incompatible changes inside the V2 API we're
> just hiding the fact that we in fact have two different APIs. We're not
> actually reducing the maintenance cost and it comes at increased user
> confusion, not less. In some areas of testing we'll be increasing
> the work needed to be done. Eg we need to make sure we're doing
> something sane when someone passes say:
> 
> onSharedStorage = True
> on_shared_storage = False
> 
> should the old or new behaviour get priority? Or should we instead
> return a 400? We don't need to have that logic (or testing) when we
> cleanly separate the new API from the old one. Similar issues when
> passing a mixture of old and new formats. Should that be valid? If not
> we need to explicitly check and reject.

I think in cases like this, we should only have the old behavior.  I'm
not sure I see much value in making these changes in v2 at all.

-- 
Russell Bryant