Open Stack

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

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

Chris