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