-----Original Message----- From: openstack-bounces+rob_hirschfeld=dell...@lists.launchpad.net [mailto:openstack-bounces+rob_hirschfeld=dell...@lists.launchpad.net] On Behalf Of Dan Wendlandt Sent: Friday, August 24, 2012 5:39 PM To: open...@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,