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-requ...@lists.openstack.org?subject:unsubscribe > http://lists.openstack.org/cgi-bin/mailman/listinfo/openstack-dev -- Thanks, Nikhil __________________________________________________________________________ OpenStack Development Mailing List (not for usage questions) Unsubscribe: openstack-dev-requ...@lists.openstack.org?subject:unsubscribe http://lists.openstack.org/cgi-bin/mailman/listinfo/openstack-dev