Open Stack

On 4/6/16 2:09 PM, Clint Byrum wrote:
> Excerpts from Nikhil Komawar's message of 2016-04-06 10:46:28 -0700:
>> Need a inline clarification.
>>
>> On 4/6/16 10:58 AM, Flavio Percoco wrote:
>>> On 06/04/16 08:26 -0400, Sean Dague wrote:
>>>> On 04/06/2016 04:13 AM, Markus Zoeller wrote:
>>>>> +1 for deprecation and removal
>>>>>
>>>>> To be honest, when I started with Nova during Kilo, I didn't get
>>>>> why we have those passthrough APIs. They looked like convenience APIs.
>>>>> A short history lesson, why they got introduced, would be cool. I only
>>>>> found commit [1] which looks like they were there from the beginning.
>>>>>
>>>>> References:
>>>>> [1]
>>>>> https://github.com/openstack/python-novaclient/commit/7304ed80df265b3b11a0018a826ce2e38c052572#diff-56f10b3a40a197d5691da75c2b847d31R33
>>>>>
>>>> The short history lesson is nova image API existed before glance. Glance
>>>> was a spin out from Nova of that API. Doing so doesn't immediately make
>>>> that API go away however. Especially as all these things live on
>>>> different ports with different end points. So the image API remained as
>>>> a proxy (as did volumes, baremetal, and even to some extend networks).
>>>>
>>>> It's not super clear how you deprecate and remove these things without
>>>> breaking a lot of people, as a lot of the libraries implement the nova
>>>> image resources -
>>>> https://github.com/fog/fog-openstack/blob/master/lib/fog/openstack/compute.rb
>>>>
>>> We can deprecate it without removing it. We make it work with v2 and
>>> start
>>> warning people that the API is not supported anymore. We don't fix
>>> bugs in that
>>> API but tell people to use the newer version.
>>>
>>> I think that should do it, unless I'm missing something.
>>> Flavio
>>>
>> Is it a safe practice to not fix bugs on a publicly exposed API? What
>> are the recommendations for such cases?
>>
> I don't think you can make a blanket statement that no bugs will be
> fixed.
>
> There are going to be evolutions behind this API that make a small bug
> today into a big bug tomorrow. The idea is to push the user off the API
> when they try to do more with it, not when we forcibly explode their
> working code.
>
> "We don't break userspace". I know _we_ didn't say that about our
> project. But I like to think we understand the wisdom behind that, and can
> start at least pretending we believe in ourselves and our users enough
> to hold to it for some things, even if we don't really like some of the
> more dark and dingy corners of userspace that we have put out there.

I see, so here's a more subjective idea of how we want to handle such
sensitive (being used for long time, important for some core operations,
etc) APIs and fix bugs on a case by case basis. We may be going in a
positive direction by reducing support but amount of work wise, I think
we can set expectations for developers as more process and less fixing.

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

-- 

Thanks,
Nikhil