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: >>> [email protected]?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 __________________________________________________________________________ OpenStack Development Mailing List (not for usage questions) Unsubscribe: [email protected]?subject:unsubscribe http://lists.openstack.org/cgi-bin/mailman/listinfo/openstack-dev
