On 09/03/2012 08:47 PM, [email protected] 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:[email protected]]
Sent: Monday, August 27, 2012 12:57 PM
To: Hirschfeld, Rob
Cc: [email protected]; [email protected]
Subject: Re: [Openstack] Quantum vs. Nova-network in Folsom
On Sun, Aug 26, 2012 at 12:39 PM,<[email protected]> 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: [email protected]
[mailto:[email protected]]
On Behalf Of Dan Wendlandt
Sent: Friday, August 24, 2012 5:39 PM
To: [email protected]; 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 : [email protected]
Unsubscribe : https://launchpad.net/~openstack
More help : https://help.launchpad.net/ListHelp
--
~~~~~~~~~~~~~~~~~~~~~~~~~~~
Dan Wendlandt
Nicira, Inc: www.nicira.com
twitter: danwendlandt
~~~~~~~~~~~~~~~~~~~~~~~~~~~
_______________________________________________
Mailing list: https://launchpad.net/~openstack
Post to : [email protected]
Unsubscribe : https://launchpad.net/~openstack
More help : https://help.launchpad.net/ListHelp
_______________________________________________
Mailing list: https://launchpad.net/~openstack
Post to : [email protected]
Unsubscribe : https://launchpad.net/~openstack
More help : https://help.launchpad.net/ListHelp
