On 1/29/2014 10:47 AM, Russell Bryant wrote:
Greetings,
A while back I mentioned that we would revisit the potential deprecation
of nova-network in Icehouse after the icehouse-2 milestone. The time
has come. :-)
First, let me recap my high level view of the blockers to deprecating
nova-network in favor of Neutron:
- Feature parity
- The biggest gap here has been nova-network's multi-host mode.
Neutron needs some sort of HA for l3 agents, as well as the
ability to run in a mode that enables a single tenant's traffic
to be actively handled by multiple nodes.
- Testing / Quality parity
- Neutron needs to reach testing and quality parity in CI. This
includes running the full tempest suite, for example. For all
tests run against nova with nova-network that are applicable, they
need to be run against Neutron, as well. All of these jobs should
have comparable or better reliability than the ones with
nova-network.
- Production-ready open source components
- nova-network provides basic, but usable in production networking
based purely on open source components. Neutron must have
production-ready options based purely on open source components,
as well, that provides comparable or better performance and
reliability.
First, I would like to say thank you to those in the Neutron team that
have worked hard to make progress in various areas. While there has
been good progress, we're not quite there on achieving these items. As
a result, nova-network will *not* be marked deprecated in Icehouse. We
will revisit this question again in a future release. I'll leave it to
the Neutron team to comment further on the likelihood of meeting these
goals in the Juno development cycle.
Regarding nova-network, I would like to make some changes. We froze
development on nova-network in advance of its deprecation.
Unfortunately, this process has taken longer than anyone thought or
hoped. This has had some negative consequences on the nova-network code
(such as [1]).
Effective immediately, I would like to unfreeze nova-network
development. What this really means:
- We will no longer skip nova-network when making general
architectural improvements to the rest of the code. An example
of playing catch-up in nova-network is [2].
- We will accept new features, evaluated on a case by case basis,
just like any other Nova feature. However, we are explicitly
*not* interested in features that widen the parity gaps between
nova-network and Neutron.
- While we will accept incremental features to nova-network, we
are *not* interested in increasing the scope of nova-network
to include support of any SDN controller. We leave that as
something exclusive to Neutron.
I firmly believe that Neutron is the future of networking for OpenStack.
We just need to loosen up nova-network to move it along to ease some
pressure and solve some problems as we continue down this transition.
Thanks,
[1]
http://lists.openstack.org/pipermail/openstack-dev/2014-January/024052.html
[2] https://blueprints.launchpad.net/nova/+spec/nova-network-objects
Timely thread. I was just going through nova/neutron-related blueprints
and patches yesterday for Icehouse and noted these as something I think
we definitely need as pre-reqs before going all-in with neutron:
https://blueprints.launchpad.net/neutron/+spec/instance-nw-info-api
https://bugs.launchpad.net/nova/+bug/1255594
https://bugs.launchpad.net/nova/+bug/1258620
There are patches up for the two bugs, but they need some work.
--
Thanks,
Matt Riedemann
_______________________________________________
OpenStack-dev mailing list
OpenStack-dev@lists.openstack.org
http://lists.openstack.org/cgi-bin/mailman/listinfo/openstack-dev
