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 <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.
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-requ...@lists.openstack.org?subject:unsubscribe
http://lists.openstack.org/cgi-bin/mailman/listinfo/openstack-dev
