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