Open Stack

On 4/6/2016 1:17 PM, Nikhil Komawar wrote:
>
>
> 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
>

This thread has gotten longer and more complicated than I expected.

At a very basic level, we aren't going to (knowingly) break the nova 
images API if using glance v2 on the backend, that's where a translation 
layer has to come in as part of the glance v2 adoption.

But the nova images API is feature frozen, meaning we aren't going to 
make it handle glance v2-like requests. The same is true for how we 
don't have volume-type support in the nova volume create API.

So now that we can all agree that we aren't removing the nova images API 
and we aren't going to break it for glance v2 adoption, we can also 
agree that we don't want people using it.

One of the entry points to using it is via the CLI and python API 
bindings in python-novaclient. Hence why I'm proposing that we deprecate 
and eventually remove those. That's not a dependency for glance v2 
adoption in nova, it's just a parallel thing we should have already done 
awhile back.

OK, I think that's it.

-- 

Thanks,

Matt Riedemann