On 04/10/2017 10:24 AM, Sean Dague wrote:
On 04/10/2017 11:19 AM, Matt Riedemann wrote:
On 4/10/2017 9:19 AM, Dean Troyer wrote:
On Mon, Apr 10, 2017 at 8:58 AM, Akihiro Motoki <amot...@gmail.com>
(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.


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.

Right, I guess I'm confused why the operator in that case would just
keep the older version installed. It's not being deleted from pypi.

I think it's, as usual, two different use cases. The operator and the end-user are different. I think nova has done an excellent job signaling this for operators.

However, one of the places where it may have fallen down is that users of python-openstackclient are not necessarily deployers, and they may also have accounts on clouds that still force people through the nova proxy apis - (and hell no to having a copy of python-openstackclient for each cloud, that's crazy)- AND - python-openstackclient depends on python-novaclient.

python-openstackclient is fixing this the same way as shade - not using python-novaclient but instead using REST calls. I think this is the right solution.

But right solution or not right solution, python-*client have historically been the thing we've pointed end-users at as a way to consume our clouds, and as much as we've been pushing moving the services forward, we haven't been as agressive in communicating to our end users to NEVER EVER EVER use python-*client for ANY REASON but instead to use python-openstackclient for command line and either shade or openstacksdk for python programming. A lot of that is inertia - people are used to typing "nova boot" - but the time is long past and this is a really great example of why it's really REALLY important to communicate strongly and clearly that end-users should not use the legacy python clients.


OpenStack Development Mailing List (not for usage questions)
Unsubscribe: openstack-dev-requ...@lists.openstack.org?subject:unsubscribe

Reply via email to