Open Stack

On 4/10/2017 11:14 AM, Monty Taylor wrote:
> 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.
>
> __________________________________________________________________________
> OpenStack Development Mailing List (not for usage questions)
> Unsubscribe: OpenStack-dev-request at lists.openstack.org?subject:unsubscribe
> http://lists.openstack.org/cgi-bin/mailman/listinfo/openstack-dev

Thanks for the clarification and continuing to keep end users in mind.

-- 

Thanks,

Matt