← Back to team overview

openstack team mailing list archive

Re: Quantum vs. Nova-network in Folsom

 

On 4 September 2012 22:16, Trey Morris <trey.morris@xxxxxxxxxxxxx> wrote:

> The transition is going to be difficult either way when you consider data
> migrations..


This is one huge aspect. The other concerns deployment, as Quantum
interacts with nova-compute in a quite different way and roll out Quantum
to replace nova-network is going to be tricky, and the Quantum community
should probably start thinking about strategies and best practices for this
migration.
I don't see however being in a state where nova-network is going to be
deprecated and removed anytime soon; partly because of some gaps still
existing, and partly because of use cases, especially flat networks, where
quantum adds little to no benefit in terms of feature.


> Gary, I've scheduled a talk about the future of nova networking. I hope it
> to be an open forum of ideas.
>

Trey, I hope you are allocating a fair amount of time in your session to
discuss migration as well.


> Also, for what it's worth, I'd like to keep quantum code and nova code as
> separate as possible even if ovs is added to nova's network capabilities.
>

Totally agree.


>
> -tr3buchet
>
> On Tue, Sep 4, 2012 at 1:15 AM, Gary Kotton <gkotton@xxxxxxxxxx> wrote:
>
>> On 09/03/2012 08:47 PM, Rob_Hirschfeld@xxxxxxxx wrote:
>>
>>> Dan,
>>>
>>> The challenge here is how to wean off one code base (Nova Net) and into
>>> another (Quantum).
>>>
>>> My thinking was that we'd be able to have more shared components and
>>> possibly shared code.   This could ease the transition by having operators
>>> gain experience with Open vSwitch.  Unfortunately, it is likely to also
>>> slow the transition because it would be investing more development effort
>>> in Nova Networking.
>>>
>>
>> At the moment Quantum supports a number of different technologies, one of
>> them is Open vSwitch. I think that if the focus is taken to integrate OVS
>> directly into nova networking this would hinder both Nova Networking and
>> Quantum. If the resources can be focused on Quantum then we can have one
>> solution that supports a variety of networking technologies.
>>
>> I think that if we focus our resources then hopefully by G-1 we can have
>> Quantum replacing the traditional nova networking. I am not sure if a
>> session is planned for the summit around this but it would be very good to
>> discuss.
>>
>>
>>
>>> Note: I'm sorry about the delay in replying.  I off so I could include
>>> some perspective from investigation.  It showed that some of the simplest
>>> Nova networking modes could use vSwitch but the popular ones would require
>>> duplicating/porting Quantum code back to Nova.
>>>
>>
>> You can do this if you want to very basic bridging. But when you want to
>> expose OpenFlow and other technologies you will most probably take a
>> approach similar to that of Quantum.
>>
>> That is my two cents.
>> Thanks
>> Gary
>>
>>
>>> Once of the things that I believe could help migration is getting
>>> Quantum API integrates into abstractions like Fog.  In fact, I've proposed
>>> a Summit topic about exactly that.
>>>
>>
>> This sounds interesting. It seems that there is also some overlapping -
>> for example the address management and DHCP handing by Quantum and FOG
>>
>>
>>> Thanks,
>>>
>>> Rob
>>>
>>> -----Original Message-----
>>> From: Dan Wendlandt [mailto:dan@xxxxxxxxxx]
>>> Sent: Monday, August 27, 2012 12:57 PM
>>> To: Hirschfeld, Rob
>>> Cc: openstack@xxxxxxxxxxxxxxxxxxx; openstack-dev@lists.openstack.**org<openstack-dev@xxxxxxxxxxxxxxxxxxx>
>>> Subject: Re: [Openstack] Quantum vs. Nova-network in Folsom
>>>
>>> On Sun, Aug 26, 2012 at 12:39 PM,<Rob_Hirschfeld@xxxxxxxx>  wrote:
>>>
>>>> Stackers,
>>>>
>>>> I think this is a reasonable approach and appreciate the clarification
>>>> of use-cases.
>>>>
>>>> We've been discussing using Open vSwitch as the basis for non-Quantum
>>>> Nova Networking deployments in Folsom.  While not Quantum, it feels like
>>>> we're bringing Nova Networking a step closer to some of the core
>>>> technologies that Quantum uses.
>>>>
>>>> I'm interested in hearing what other's in the community think about
>>>> this approach.
>>>>
>>> One of the main reasons we introduced Quantum was to support alternative
>>> switching technologies like Open vSwitch.  I'd like to hear more about your
>>> thoughts, but at first glance, I'm not sure there's a good way to leverage
>>> Open vSwitch in a meaningful way with existing nova-network managers, since
>>> those network managers are so tightly tied to using the basic linux bridge
>>> + vlans.
>>>
>>> Dan
>>>
>>>  Rob
>>>>
>>>> -----Original Message-----
>>>> From: openstack-bounces+rob_**hirschfeld=dell.com@lists.**launchpad.net<dell.com@xxxxxxxxxxxxxxxxxxx>
>>>> [mailto:openstack-bounces+rob_**hirschfeld<openstack-bounces%2Brob_hirschfeld>
>>>> =dell.com@lists.**launchpad.net <dell.com@xxxxxxxxxxxxxxxxxxx>]
>>>> On Behalf Of Dan Wendlandt
>>>> Sent: Friday, August 24, 2012 5:39 PM
>>>> To: openstack@xxxxxxxxxxxxxxxxxxx; OpenStack Development Mailing List
>>>> Subject: [Openstack] Quantum vs. Nova-network in Folsom
>>>>
>>>> tl;dr  both Quantum and nova-network will be core and fully supported
>>>> in Folsom.
>>>>
>>>> Hi folks,
>>>>
>>>> Thierry, Vish and I have been spending some talking about OpenStack
>>>> networking in Folsom, and in particular the availability of nova-network
>>>> now that Quantum is a core project.  We wanted to share our current
>>>> thinking with the community to avoid confusion.
>>>>
>>>> With a project like OpenStack, there's a fundamental trade-off between
>>>> the rate of introducing new capabilities and the desire for stability and
>>>> backward compatibility.  We agreed that OpenStack is a point in its growth
>>>> cycle where the cost of disruptive changes is high.  As a result, we've
>>>> decided that even with Quantum being core in Folsom, we will also continue
>>>> to support nova-network as it currently exists in Folsom.  There is, of
>>>> couse, overhead to this approach, but we think it is worth it.
>>>>
>>>> With this in mind, a key question becomes: how do we "direct" users to
>>>> the networking option that is right for them.  We have the following
>>>> guidelines:
>>>>
>>>> 1) For users who require only very basic networking (e.g., nova-network
>>>> Flat, FlatDHCP) there's little difference between Quantum and nova-network
>>>> is such basic use cases, so using nova's built-in networking for these
>>>> basic use cases makes sense.
>>>>
>>>> 2) There are many use cases (e.g., tenant API for defined topologies
>>>> and addresses) and advanced network technologies (e.g., tunneling rather
>>>> than VLANs) that Quantum enables that are simply not possible with
>>>> nova-network, so if these advanced capabilities are important to someone
>>>> deploying OpenStack, they clearly need to use Quantum.
>>>>
>>>> 3) There are a few things that are possible in nova-network, but not in
>>>> Quantum.  Multi-host is the most significant one, but there are bound to be
>>>> other gaps, some of which we will uncover only when people try their
>>>> particular use case with Quantum.  For these, users will have to use
>>>> nova-network, with the gaps being covered in Quantum during Grizzly.
>>>>
>>>> As a result, we plan to structure the docs so that you can do a basic
>>>> functionality Nova setup with flat networking without requiring Quantum.
>>>>  For anything beyond that, we will have an "advanced networking" section,
>>>> which describes the different advanced use of OpenStack networking with
>>>> Quantum, and also highlight reasons that a user may still want to use
>>>> nova-networking over Quantum.
>>>>
>>>> Moving beyond Folsom, we expect to fully freeze the addition of new
>>>> functionality to nova-network, and likely deprecate at least some portions
>>>> of the existing nova-network functionality.  Likely this will leave the
>>>> basic flat and flat + dhcp nova networking intact, but reduce complexity in
>>>> the nova codebase by removing more advanced networking scenarios that can
>>>> also be achieved via Quantum.  This means that even those using
>>>> nova-network in Folsom should still be evaluating Quantum if they
>>>> networking needs beyond flat networking, such that this feedback can be
>>>> incorporated into the Grizzly deliverable of Quantum.
>>>>
>>>> Thanks,
>>>>
>>>> Dan
>>>>
>>>>
>>>> --
>>>> ~~~~~~~~~~~~~~~~~~~~~~~~~~~
>>>> Dan Wendlandt
>>>> Nicira, Inc: www.nicira.com
>>>> twitter: danwendlandt
>>>> ~~~~~~~~~~~~~~~~~~~~~~~~~~~
>>>>
>>>> ______________________________**_________________
>>>> Mailing list: https://launchpad.net/~**openstack<https://launchpad.net/~openstack>
>>>> Post to     : openstack@xxxxxxxxxxxxxxxxxxx
>>>> Unsubscribe : https://launchpad.net/~**openstack<https://launchpad.net/~openstack>
>>>> More help   : https://help.launchpad.net/**ListHelp<https://help.launchpad.net/ListHelp>
>>>>
>>>
>>>
>>> --
>>> ~~~~~~~~~~~~~~~~~~~~~~~~~~~
>>> Dan Wendlandt
>>> Nicira, Inc: www.nicira.com
>>> twitter: danwendlandt
>>> ~~~~~~~~~~~~~~~~~~~~~~~~~~~
>>>
>>> ______________________________**_________________
>>> Mailing list: https://launchpad.net/~**openstack<https://launchpad.net/~openstack>
>>> Post to     : openstack@xxxxxxxxxxxxxxxxxxx
>>> Unsubscribe : https://launchpad.net/~**openstack<https://launchpad.net/~openstack>
>>> More help   : https://help.launchpad.net/**ListHelp<https://help.launchpad.net/ListHelp>
>>>
>>
>>
>> ______________________________**_________________
>> Mailing list: https://launchpad.net/~**openstack<https://launchpad.net/~openstack>
>> Post to     : openstack@xxxxxxxxxxxxxxxxxxx
>> Unsubscribe : https://launchpad.net/~**openstack<https://launchpad.net/~openstack>
>> More help   : https://help.launchpad.net/**ListHelp<https://help.launchpad.net/ListHelp>
>>
>
>
> _______________________________________________
> Mailing list: https://launchpad.net/~openstack
> Post to     : openstack@xxxxxxxxxxxxxxxxxxx
> Unsubscribe : https://launchpad.net/~openstack
> More help   : https://help.launchpad.net/ListHelp
>
>

Follow ups

References