Open Stack

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 <amotoki at 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.
>
> 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.

Monty