[openstack-dev] [tc] [all] [glance] Answers to some questions about Glance

Nikhil Komawar nik.komawar at gmail.com
Wed May 18 16:52:33 UTC 2016

Thank you for stating all the right things Brian.

And I want to add that Glance too takes it to heart.

We needed a major version change and that's been communicated in many
ways. If more documentation, etc stuff is required, you are welcome to
provide that feedback. We are more than happy to help where required.

NOTE FOR ALL: We've spent 170,020,783 Calories on this version change
topic. It's done and we will have to live with it.

That's it. Time to pack up here.

On 5/18/16 8:44 AM, Brian Rosmaita wrote:
> On 5/18/16, 2:15 AM, "Clint Byrum" <clint at fewbar.com> wrote:
>> Excerpts from Robert Collins's message of 2016-05-18 14:57:05 +1200:
>>> 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
>>> example of why Monty has been pushing on 'never break our APIs': API
>>> 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.
>>> 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.
>> +1, realy well said. As Nikhil said, assumptions are bad, and assuming
>> that nobody's using that, or that they'll just adapt, is not really a
>> great way to establish a relationship with the users.
> I agree with the general sentiment, and I sincerely hope that all
> OpenStack projects take it to heart.
> I also want to note for the record that the Images API really did need a
> major version change.
> cheers,
> brian
> __________________________________________________________________________
> OpenStack Development Mailing List (not for usage questions)
> Unsubscribe: OpenStack-dev-request at lists.openstack.org?subject:unsubscribe
> http://lists.openstack.org/cgi-bin/mailman/listinfo/openstack-dev



More information about the OpenStack-dev mailing list