On 4/10/2017 9:19 AM, Dean Troyer wrote:
On Mon, Apr 10, 2017 at 8:58 AM, Akihiro Motoki <amot...@gmail.com> wrote:
(question not directly related to this topic)
I am not sure there is a case where users still use API 2.36 for
network management
and newer API versions for other compute operation.

This is probably true for Horizon, where the app install likely
matches the cloud it is configured to use.  However, many other use
cases for the Python libraries are meant to talk to multiple versions
of clouds and the 8.0 release of novaclient causes problems there.

Even after nova-net support is EOL officially OSC plans to support the
use of nova-net for some time.  We are re-implementing the removed
functionality locally.  And anticipating some of the questions why,
consider an operator working on the long migration/upgrade from a
deployed nova-net cloud to a Neutron cloud, and needing to keep at
least one foot in both worlds.  There are other similar uses.

dt


As noted in my reply to Akihiro, the CLIs/APIs were deprecated in novaclient back in Newton in the 6.0.0 release of python-novaclient. We left them through Ocata and dropped them here in Pike in 8.0.0.

How long are we expected to be carrying this deprecated bridge code? If you need these CLIs/API bindings in the client, then don't upgrade to 8.0.0, or run different versions of novaclient in venvs or containers if you need to really workaround this.

I feel like the signaling on all of this was pretty clear back in Newton. What else are people expecting or that we missed? I don't really see why python-openstackclient needs to start adding this API binding code back in locally, that's just extending the lifespan of this busted code that we're really trying to make uncomfortable for people to be using because like it or not, nova-network is going away. We did the fallback thing in the CLI in newton as a way to soften that blow for CLI users, but really at some point this just needs to be broken and people either stay on old tools or upgrade to what is supported.

--

Thanks,

Matt

__________________________________________________________________________
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

Reply via email to