[openstack-dev] [tc] [all] [glance] Answers to some questions about Glance
nik.komawar at gmail.com
Wed May 18 16:34:50 UTC 2016
All great points. But, I just want us to read between the lines.
On 5/17/16 10:57 PM, Robert Collins wrote:
> On 18 May 2016 at 00:54, Brian Rosmaita <brian.rosmaita at rackspace.com> wrote:
>>> Couple of examples:
>>> 1. switching from "is_public=true" to "visibility=public"
>> This was a major version change in the Images API. The 'is_public' boolean
>> is in the original Images v1 API, 'visibility' was introduced with the
>> Images v2 API in the Folsom release. You just need an awareness of which
>> version of the API you're talking to.
> So I realise this is ancient history, but this is really a good
Thank you for realizing that! Whatever keeps us from reopening this
pandora's box again!
> example of why Monty has been pushing on 'never break our APIs': API
Sure, we need to consider when that was proposed and how OpenStack was
operating before, who were the major stakeholders and why certain things
needed to be changed. I am not arguing against your point, rather saying
for sake of supporting an API that will remain maintainable long term.
Have we considered all the things are important like security before
saying that we need backward compatibility or are we willing to
compromise on that?, I guess not.
> breaks hurt users, major versions or not. Keeping the old attribute as
> an alias to the new one would have avoided the user pain for a very
> small amount of code.
Again, we need to be careful about this, keep the compatibility when it
makes sense and is possible. Having to maintain a hacky code is pretty
bad idea I'd say.
> We are by definition an API - doesn't matter that its HTTP vs Python -
> when we break compatibility, there's a very long tail of folk that
> will have to spend time updating their code; 'Microversions' are a
> good answer to this, as long as we never raise the minimum version we
> support. glibc does a very similar thing with versioned symbols - and
> they support things approximately indefinitely.
All good points and we are going in that direction. Thanks for stating
> OpenStack Development Mailing List (not for usage questions)
> Unsubscribe: OpenStack-dev-request at lists.openstack.org?subject:unsubscribe
More information about the OpenStack-dev