openstack team mailing list archive

[Trey Morris <trey.morris@xxxxxxxxxxxxx>]

The transition is going to be difficult either way when you consider data
migrations..
Gary, I've scheduled a talk about the future of nova networking. I hope it
to be an open forum of ideas.
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.

-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>
>