Open Stack

On 4/6/16 2:43 PM, Matt Riedemann wrote:
>
>
> 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 for the clarification and giving us a complete outline of the
plan. It makes sense.

-- 

Thanks,
Nikhil