Open Stack

On Sun, Aug 26, 2012 at 12:39 PM,  <Rob_Hirschfeld at dell.com> 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 at lists.launchpad.net [mailto:openstack-bounces+rob_hirschfeld=dell.com at lists.launchpad.net] On Behalf Of Dan Wendlandt
> Sent: Friday, August 24, 2012 5:39 PM
> To: openstack at lists.launchpad.net; 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
> Post to     : openstack at lists.launchpad.net
> Unsubscribe : https://launchpad.net/~openstack
> More help   : https://help.launchpad.net/ListHelp



-- 
~~~~~~~~~~~~~~~~~~~~~~~~~~~
Dan Wendlandt
Nicira, Inc: www.nicira.com
twitter: danwendlandt
~~~~~~~~~~~~~~~~~~~~~~~~~~~