Open Stack

On 04/10/2017 10:37 AM, Monty Taylor wrote:
> On 04/10/2017 09: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.
>
> I agree - I think it is not important for horizon to support backward
> compat - it's most commonly deployed with a cloud, so one expects it to
> support the software in the cloud in question.
>
>> 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.
>
> Similarly, shade intends to support nova-net for as long as shade
> exists. We have already re-implemented most of nova-net support with
> direct calls as part of our current project to delete use of
> python-*client.

> It turns out there are humans out there who are consuming old clouds -
> and end-user client tools should be supporting those humans, even when
> the current releases of OpenStack deprecate/remove things.

Quick clarification ...

When I say "shade intends to support nova-net" - I mean a specific thing 
that is almost certainly not what you might at first assume.

 From the beginning, shade has hidden the nova-net/neutron difference - 
but shade is focused on the end-user primarily. This means the 
difference is "do you use nova or neutron API to deal with floating IPs 
and security groups" We do not expose any nova-net functionality 
directly - we expose FIPs and Security Groups, and we hide from the user 
what service provides them.

We will continue to do that to the best of our ability - although 
functional testing in devstack will have to give way to only 
requests-mock based testing once we don't have old stable branches that 
can install nova-net.

I may have also given the impression that I'm unhappy about novaclient 
dropping support - which is also not the case. I am firmly of the 
opinion that python-*client do not have end-users of OpenStack clouds as 
primary users in mind. The release model and design just isn't right for 
that. They are clearly, to me, designed to aid intra-service 
communication. As such, I think it's 100% appropriate for novaclient to 
have dropped nova-net support.

I, for one, welcome all things about the removal of nova-net, and I am 
quite happy to do the support actions in shade.