[openstack-dev] [nova] future fate of nova-network?

Gary Kotton gkotton at vmware.com
Sat Nov 23 15:44:43 UTC 2013

On 11/22/13 2:47 PM, "Daniel P. Berrange" <berrange at redhat.com> wrote:

>On Fri, Nov 22, 2013 at 11:25:51AM +0000, John Garbutt wrote:
>> >> On Fri, Nov 15, 2013 at 2:21 PM, Russell Bryant <rbryant at redhat.com>
>> >>>> In particular, has there been a decision made about whether it will
>> >>>> definitely be deprecated in some (as yet unspecified) future
>>release, or
>> >>>> whether it will continue to be supported for the foreseeable
>> >>>
>> >>> We want to deprecate it.  There are some things blocking moving
>> >>> with this.  In short:
>> >>>
>> >>> 1) Feature parity (primarily something that satisfies performance
>>and HA
>> >>> requirements addressed by nova-network in multi-host mode)
>> >>>
>> >>> 2) Testing and quality parity.  The status of Neutron testing in the
>> >>> gate is far inferior to the testing done against nova-network.
>> >>>
>> >>> I'm personally more worried about #2 than #1 at this point.
>> >>>
>> >>> A major issue is that very few people actually stepped up and
>>agreed to
>> >>> help with #2 at the summit [2].  Only one person signed up to work
>> >>> tempest issues.  Nobody signed up to help with grenade.  If this
>> >>> happen, nova-network can't be deprecated, IMO.
>> >>>
>> >>> If significant progress isn't made ASAP this cycle, and ideally by
>> >>> mid-cycle so we can change directions if necessary, then we'll have
>> >>> discuss what next step to take.  That may include un-freezing
>> >>> nova-network so that various people holding on to enhancements to
>> >>> nova-network can start submitting them back.  It's a last resort,
>>but I
>> >>> consider it on the table.
>> Another approach to help with (1) is in Icehouse we remove the
>> features from nova-network that neutron does not implement. We have
>> warned about deprecation for a good few releases, so its almost OK.
>We deprecated it on the basis that users would be able to do a upgrade
>to new release providing something that was feature equivalent.
>We didn't deprecate it on the basis that we were going to remove the
>feature and provide no upgrade path, leaving users screwed.
>So I don't consider removing features from nova-network to be an
>acceptable approach, until they exist in Neutron or something else
>that users can upgrade their existing deployments to.

As far as I see it the only thing that is missing for parity today is the
HA for the floating IP's. A partial solution was added and this was
dropped due to disagreement in the Neutron community. What I think that a
lot of people miss is that the HA floating IP support in Nova is not
really scalable and that is where the Neutron solution fills a void.

One of the items we spoke about at summit was fixing the interfaces with
Neutron - today a ton of work is done on the compute node and this should
be done elsewhere - either on the conductor or at the API level. My
feeling is that a this provide a more robust solution. The original Nova
network solution was a lot simpler as as the hypervisor was controlling
the network - this was a matter of just hooking up some bridges (and there
are still bug fix trickling in). With the advent of SDN there are 3rd
party controllers that do that and the solution becomes a lot more complex.

I do not think that features being used should be deprecated. But I think
that we should try and draw up a plan to move forwards.

>9b2116f01a609be9851c2efc1bb5080f1e81f6373150799636      -o-
>0A&s=7d93f60bdf39912d9d28058a3ae257f8e82243386aa585913a0c0b23755e65ed :|
>cc1847702b19a675ecaa5e89509dbced8aaa04302a4b30cf3              -o-
>99aeaa02ff5a3f7d2a6cfb69fa6d350c0d6e379b07023b4d0b5f13 :|
>bcb11642867a97e5149591089e23137c5b8388dae546a97f801       -o-
>8acdd0ac83e97c9e5b26dce7599a705765e3f0b0eff8a3afef07673ece09b9 :|
>919312ff0179d42289228d81f0ade8c089f9907a0a27ce65ce0075ea       -o-
>058492b3274f14df76407443a1d19edc3c53267e6ef5d608887e088847c :|
>OpenStack-dev mailing list
>OpenStack-dev at lists.openstack.org

More information about the OpenStack-dev mailing list