Mailing List Archive: OpenStack: Dev

Quantum vs. Nova-network in Folsom

Index | Next | Previous | View Threaded

dan at nicira

Aug 24, 2012, 3:39 PM

Post #1 of 22 (2700 views)
Permalink

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
Unsubscribe : https://launchpad.net/~openstack
More help : https://help.launchpad.net/ListHelp

Rob_Hirschfeld at Dell

Aug 26, 2012, 12:39 PM

Post #2 of 22 (2654 views)
Permalink

Re: Quantum vs. Nova-network in Folsom [In reply to]

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.

Rob

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

_______________________________________________
Mailing list: https://launchpad.net/~openstack
Post to : openstack [at] lists
Unsubscribe : https://launchpad.net/~openstack
More help : https://help.launchpad.net/ListHelp

chrisw at sous-sol

Aug 27, 2012, 9:21 AM

Post #3 of 22 (2667 views)
Permalink

Re: Quantum vs. Nova-network in Folsom [In reply to]

* Rob_Hirschfeld [at] Dell (Rob_Hirschfeld [at] Dell) wrote:
> 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.

To what end?

> I'm interested in hearing what other's in the community think about this approach.

I don't think legacy nova networking should get features while working to
stabilize and improve quantum and nova/quantum integration.

thanks,
-chris

_______________________________________________
Mailing list: https://launchpad.net/~openstack
Post to : openstack [at] lists
Unsubscribe : https://launchpad.net/~openstack
More help : https://help.launchpad.net/ListHelp

dan at nicira

Aug 27, 2012, 10:56 AM

Post #4 of 22 (2642 views)
Permalink

Re: Quantum vs. Nova-network in Folsom [In reply to]

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

Rob_Hirschfeld at Dell

Sep 3, 2012, 10:47 AM

Post #5 of 22 (2620 views)
Permalink

Re: Quantum vs. Nova-network in Folsom [In reply to]

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.

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.

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.

Thanks,

Rob

-----Original Message-----
From: Dan Wendlandt [mailto:dan [at] nicira]
Sent: Monday, August 27, 2012 12:57 PM
To: Hirschfeld, Rob
Cc: openstack [at] lists; openstack-dev [at] lists
Subject: Re: [Openstack] Quantum vs. Nova-network in Folsom

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

gkotton at redhat

Sep 3, 2012, 11:15 PM

Post #6 of 22 (2610 views)
Permalink

Re: Quantum vs. Nova-network in Folsom [In reply to]

On 09/03/2012 08:47 PM, Rob_Hirschfeld [at] Dell 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 [at] nicira]
> Sent: Monday, August 27, 2012 12:57 PM
> To: Hirschfeld, Rob
> Cc: openstack [at] lists; openstack-dev [at] lists
> Subject: Re: [Openstack] Quantum vs. Nova-network in Folsom
>
> On Sun, Aug 26, 2012 at 12:39 PM,<Rob_Hirschfeld [at] dell> 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
>> [mailto:openstack-bounces+rob_hirschfeld=dell.com [at] lists]
>> On Behalf Of Dan Wendlandt
>> Sent: Friday, August 24, 2012 5:39 PM
>> To: openstack [at] lists; 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
>> 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 : openstack [at] lists
> Unsubscribe : https://launchpad.net/~openstack
> More help : https://help.launchpad.net/ListHelp

_______________________________________________
Mailing list: https://launchpad.net/~openstack
Post to : openstack [at] lists
Unsubscribe : https://launchpad.net/~openstack
More help : https://help.launchpad.net/ListHelp

trey.morris at rackspace

Sep 4, 2012, 1:16 PM

Post #7 of 22 (2610 views)
Permalink

Re: Quantum vs. Nova-network in Folsom [In reply to]

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 [at] redhat> wrote:

> On 09/03/2012 08:47 PM, Rob_Hirschfeld [at] Dell 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 [at] nicira]
>> Sent: Monday, August 27, 2012 12:57 PM
>> To: Hirschfeld, Rob
>> Cc: openstack [at] lists; openstack-dev [at] lists**org<openstack-dev [at] lists>
>> Subject: Re: [Openstack] Quantum vs. Nova-network in Folsom
>>
>> On Sun, Aug 26, 2012 at 12:39 PM,<Rob_Hirschfeld [at] dell> 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<dell.com [at] lists>
>>> [mailto:openstack-bounces+rob_**hirschfeld<openstack-bounces%2Brob_hirschfeld>
>>> =dell.com [at] lists**launchpad.net <dell.com [at] lists>]
>>> On Behalf Of Dan Wendlandt
>>> Sent: Friday, August 24, 2012 5:39 PM
>>> To: openstack [at] lists; 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 [at] lists
>>> 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 [at] lists
>> 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 [at] lists
> Unsubscribe : https://launchpad.net/~**openstack<https://launchpad.net/~openstack>
> More help : https://help.launchpad.net/**ListHelp<https://help.launchpad.net/ListHelp>
>

andi.abes at gmail

Sep 5, 2012, 5:23 AM

Post #8 of 22 (2606 views)
Permalink

Re: Quantum vs. Nova-network in Folsom [In reply to]

late to the party... but I'll dabble.

On Mon, Aug 27, 2012 at 12:21 PM, Chris Wright <chrisw [at] sous-sol> wrote:
> * Rob_Hirschfeld [at] Dell (Rob_Hirschfeld [at] Dell) wrote:
>> 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.
>
> To what end?

OVS provides much more robust monitoring and operational facilities
(e.g sFlow monitoring, better switch table visibility etc).
It also provides a linux-bridge compatibility layer (ovs-brcompatd
[1]), which should work out-of-box with the linux-bridge. As such,
switching to using OVS rather than the linux bridge could be done
without any code changes to nova, just deployment changes (e.g. ensure
that ovs-brcompatd is running to intercept brctl ioctl's - [2]).

For the more adventurous, there could be any number of interesting
scenarios enabled by having access to ovs capabilities (e.g.
tunneling)

>
>> I'm interested in hearing what other's in the community think about this approach.
>

I'm similarly curious if any *operators* have experimented with OVS
and sFlow or other of its capabilities.

[1] http://openvswitch.org/cgi-bin/gitweb.cgi?p=openvswitch;a=blob_plain;f=README;hb=HEAD
[2] http://openvswitch.org/cgi-bin/ovsman.cgi?page=vswitchd%2Fovs-brcompatd.8.in

> I don't think legacy nova networking should get features while working to
> stabilize and improve quantum and nova/quantum integration.
>
> thanks,
> -chris
>
> _______________________________________________
> Mailing list: https://launchpad.net/~openstack
> Post to : openstack [at] lists
> Unsubscribe : https://launchpad.net/~openstack
> More help : https://help.launchpad.net/ListHelp

_______________________________________________
Mailing list: https://launchpad.net/~openstack
Post to : openstack [at] lists
Unsubscribe : https://launchpad.net/~openstack
More help : https://help.launchpad.net/ListHelp

sorlando at nicira

Sep 5, 2012, 5:42 AM

Post #9 of 22 (2606 views)
Permalink

Re: Quantum vs. Nova-network in Folsom [In reply to]

On 4 September 2012 22:16, Trey Morris <trey.morris [at] rackspace> 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 [at] redhat> wrote:
>
>> On 09/03/2012 08:47 PM, Rob_Hirschfeld [at] Dell 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 [at] nicira]
>>> Sent: Monday, August 27, 2012 12:57 PM
>>> To: Hirschfeld, Rob
>>> Cc: openstack [at] lists; openstack-dev [at] lists**org<openstack-dev [at] lists>
>>> Subject: Re: [Openstack] Quantum vs. Nova-network in Folsom
>>>
>>> On Sun, Aug 26, 2012 at 12:39 PM,<Rob_Hirschfeld [at] dell> 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<dell.com [at] lists>
>>>> [mailto:openstack-bounces+rob_**hirschfeld<openstack-bounces%2Brob_hirschfeld>
>>>> =dell.com [at] lists**launchpad.net <dell.com [at] lists>]
>>>> On Behalf Of Dan Wendlandt
>>>> Sent: Friday, August 24, 2012 5:39 PM
>>>> To: openstack [at] lists; 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 [at] lists
>>>> 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 [at] lists
>>> 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 [at] lists
>> 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 [at] lists
> Unsubscribe : https://launchpad.net/~openstack
> More help : https://help.launchpad.net/ListHelp
>
>

dan at nicira

Sep 5, 2012, 9:55 AM

Post #10 of 22 (2614 views)
Permalink

Re: Quantum vs. Nova-network in Folsom [In reply to]

On Wed, Sep 5, 2012 at 5:42 AM, Salvatore Orlando <sorlando [at] nicira> wrote:
>
>
> On 4 September 2012 22:16, Trey Morris <trey.morris [at] rackspace> 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.

When we talked about nova-network to Quantum migrations a few months
ago, it seemed like the best model would be a script that could read
configuration from the nova database (e.g., networks, fixed_ips,
floating_ips tables) and then perform Quantum API calls to make an
equivalent configuration. Based on the current behavior of the
Quantum integration code in Nova, I think this is still quite feasible
and is something we can focus on once we close out the Folsom release
proper. Obviously, not all config and settings will transfer over,
but it should be possible to cover the core use cases.

Dan

>
>>
>> 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 [at] redhat> wrote:
>>>
>>> On 09/03/2012 08:47 PM, Rob_Hirschfeld [at] Dell 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 [at] nicira]
>>>> Sent: Monday, August 27, 2012 12:57 PM
>>>> To: Hirschfeld, Rob
>>>> Cc: openstack [at] lists; openstack-dev [at] lists
>>>> Subject: Re: [Openstack] Quantum vs. Nova-network in Folsom
>>>>
>>>> On Sun, Aug 26, 2012 at 12:39 PM,<Rob_Hirschfeld [at] dell> 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
>>>>> [mailto:openstack-bounces+rob_hirschfeld=dell.com [at] lists]
>>>>> On Behalf Of Dan Wendlandt
>>>>> Sent: Friday, August 24, 2012 5:39 PM
>>>>> To: openstack [at] lists; 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
>>>>> 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 : openstack [at] lists
>>>> Unsubscribe : https://launchpad.net/~openstack
>>>> More help : https://help.launchpad.net/ListHelp
>>>
>>>
>>>
>>> _______________________________________________
>>> Mailing list: https://launchpad.net/~openstack
>>> Post to : openstack [at] lists
>>> Unsubscribe : https://launchpad.net/~openstack
>>> More help : https://help.launchpad.net/ListHelp
>>
>>
>>
>> _______________________________________________
>> Mailing list: https://launchpad.net/~openstack
>> Post to : openstack [at] lists
>> Unsubscribe : https://launchpad.net/~openstack
>> More help : https://help.launchpad.net/ListHelp
>>
>
>
> _______________________________________________
> Mailing list: https://launchpad.net/~openstack
> Post to : openstack [at] lists
> 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 : openstack [at] lists
Unsubscribe : https://launchpad.net/~openstack
More help : https://help.launchpad.net/ListHelp

dan at nicira

Sep 5, 2012, 10:01 AM

Post #11 of 22 (2606 views)
Permalink

Re: Quantum vs. Nova-network in Folsom [In reply to]

On Wed, Sep 5, 2012 at 5:23 AM, andi abes <andi.abes [at] gmail> wrote:
> late to the party... but I'll dabble.
>
> On Mon, Aug 27, 2012 at 12:21 PM, Chris Wright <chrisw [at] sous-sol> wrote:
>> * Rob_Hirschfeld [at] Dell (Rob_Hirschfeld [at] Dell) wrote:
>>> 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.
>>
>> To what end?
>
> OVS provides much more robust monitoring and operational facilities
> (e.g sFlow monitoring, better switch table visibility etc).

You won't find any disagreement from me about OVS having more advanced
capabilities :)

> It also provides a linux-bridge compatibility layer (ovs-brcompatd
> [1]), which should work out-of-box with the linux-bridge. As such,
> switching to using OVS rather than the linux bridge could be done
> without any code changes to nova, just deployment changes (e.g. ensure
> that ovs-brcompatd is running to intercept brctl ioctl's - [2]).

Using ovs-brcompatd would be possible, though some distros do not
package and run it by default and in general it is not the "preferred"
way to run things according to email on the OVS mailing list.

>
> For the more adventurous, there could be any number of interesting
> scenarios enabled by having access to ovs capabilities (e.g.
> tunneling)

Tunneling is definitely a huge benefit of OVS, but you still need
someone to setup the tunnels and direct packets into them correctly.
That's is exactly what the Quantum OVS plugin does and it is
completely open source and freely available, so if people want to
experiment with OVS tunneling, using Quantum would seem like the
obvious way to do this.

Dan

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

_______________________________________________
Mailing list: https://launchpad.net/~openstack
Post to : openstack [at] lists
Unsubscribe : https://launchpad.net/~openstack
More help : https://help.launchpad.net/ListHelp

chrisw at sous-sol

Sep 5, 2012, 12:25 PM

Post #12 of 22 (2610 views)
Permalink

Re: Quantum vs. Nova-network in Folsom [In reply to]

* Dan Wendlandt (dan [at] nicira) wrote:
> On Wed, Sep 5, 2012 at 5:23 AM, andi abes <andi.abes [at] gmail> wrote:
> > late to the party... but I'll dabble.
> >
> > On Mon, Aug 27, 2012 at 12:21 PM, Chris Wright <chrisw [at] sous-sol> wrote:
> >> * Rob_Hirschfeld [at] Dell (Rob_Hirschfeld [at] Dell) wrote:
> >>> 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.
> >>
> >> To what end?
> >
> > OVS provides much more robust monitoring and operational facilities
> > (e.g sFlow monitoring, better switch table visibility etc).
>
> You won't find any disagreement from me about OVS having more advanced
> capabilities :)
>
> > It also provides a linux-bridge compatibility layer (ovs-brcompatd
> > [1]), which should work out-of-box with the linux-bridge. As such,
> > switching to using OVS rather than the linux bridge could be done
> > without any code changes to nova, just deployment changes (e.g. ensure
> > that ovs-brcompatd is running to intercept brctl ioctl's - [2]).
>
> Using ovs-brcompatd would be possible, though some distros do not
> package and run it by default and in general it is not the "preferred"
> way to run things according to email on the OVS mailing list.

Indeed. While it's doable, it's not something that will hit upstream
Linux, and therefore will not be supported by some distros.

But, in general...while adding OVS support to nova networking (in the
simplest layer 2 switch mode), may not be much work. It's adding a (not
particularly useful) feature to a code base that we hope to deprecate.
And making it more useful (adding things like tunnelling) support are
really the point of Quantum.

thanks,
-chris

_______________________________________________
Mailing list: https://launchpad.net/~openstack
Post to : openstack [at] lists
Unsubscribe : https://launchpad.net/~openstack
More help : https://help.launchpad.net/ListHelp

kmestery at cisco

Sep 5, 2012, 1:14 PM

Post #13 of 22 (2605 views)
Permalink

Re: [openstack-dev] Quantum vs. Nova-network in Folsom [In reply to]

On Sep 5, 2012, at 2:25 PM, Chris Wright wrote:
> * Dan Wendlandt (dan [at] nicira) wrote:
>> On Wed, Sep 5, 2012 at 5:23 AM, andi abes <andi.abes [at] gmail> wrote:
>>> late to the party... but I'll dabble.
>>>
>>> On Mon, Aug 27, 2012 at 12:21 PM, Chris Wright <chrisw [at] sous-sol> wrote:
>>>> * Rob_Hirschfeld [at] Dell (Rob_Hirschfeld [at] Dell) wrote:
>>>>> 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.
>>>>
>>>> To what end?
>>>
>>> OVS provides much more robust monitoring and operational facilities
>>> (e.g sFlow monitoring, better switch table visibility etc).
>>
>> You won't find any disagreement from me about OVS having more advanced
>> capabilities :)
>>
>>> It also provides a linux-bridge compatibility layer (ovs-brcompatd
>>> [1]), which should work out-of-box with the linux-bridge. As such,
>>> switching to using OVS rather than the linux bridge could be done
>>> without any code changes to nova, just deployment changes (e.g. ensure
>>> that ovs-brcompatd is running to intercept brctl ioctl's - [2]).
>>
>> Using ovs-brcompatd would be possible, though some distros do not
>> package and run it by default and in general it is not the "preferred"
>> way to run things according to email on the OVS mailing list.
>
> Indeed. While it's doable, it's not something that will hit upstream
> Linux, and therefore will not be supported by some distros.
>
> But, in general...while adding OVS support to nova networking (in the
> simplest layer 2 switch mode), may not be much work. It's adding a (not
> particularly useful) feature to a code base that we hope to deprecate.
> And making it more useful (adding things like tunnelling) support are
> really the point of Quantum.
>
I think that's what this really boils down to: The entire point of Quantum was to
add feature-rich networking as it's own service to OpenStack. Hedging by
adding piecemeal features to nova-net at this point may seem ok, but it's
a slippery slope, and may end up duplicating work which has already happened
in Quantum.

Thanks,
Kyle

> thanks,
> -chris
>
> _______________________________________________
> OpenStack-dev mailing list
> OpenStack-dev [at] lists
> http://lists.openstack.org/cgi-bin/mailman/listinfo/openstack-dev

_______________________________________________
Mailing list: https://launchpad.net/~openstack
Post to : openstack [at] lists
Unsubscribe : https://launchpad.net/~openstack
More help : https://help.launchpad.net/ListHelp

slogan at broadcom

Sep 5, 2012, 1:59 PM

Post #14 of 22 (2638 views)
Permalink

Re: [openstack-dev] Quantum vs. Nova-network in Folsom [In reply to]

Backporting *would* duplicate work, by definition.

This is nothing new in the industry, the need to innovate and move forward is always at odds with the need to support legacy deployments.

Seems to me quantum is a bit of an inflection point in the life of this rather young platform, and should be considered a forcing function for those who were earlier adopters to move forward. Here's why:

One of the strongest points of quantum (in the scope of this discussion) is that it is a decoupling from nova, which should make issues like upgradability easier (assuming good API management) because it introduces an abstraction layer + implementation encapsulation. I would argue that while it might be painful to upgrade now, doing so just to get the encapsulation that quantum provides now is reason enough to want to push forward, especially since the gulf between the two will only widen going forward.

This topic of upgrading is an interesting one (perhaps one already discussed, I'm still a noob). Devstack, as useful as it is, hasn't reached its potential -- imagine it being shipped with a set of schemas (localrcs) for various deployments styles, e.g., multi-node vs single node, VXLAN vs NVGRE, X vs Y vs Z, or maybe providing a tool something like make menuconfig, or (eventually) the ability to "size up" a prior deployment and seamlessly upgrade it to a version with not much, if any, user interaction, as one might experience in the majority of cases when upgrading Ubuntu LTS releases. Worlds like this are going to be more easily implemented on top of a platform that has good API management, modularity, and encapsulation of its core components, and standardizations for how the metadata of a deployment is specified and recorded (/etc/nova/nova.conf, etc. probably already fill that role). Quantum seems to me to be a necessary (IMHO) step in that direction.

Just my two cents.

syd

-----Original Message-----
From: openstack-bounces+slogan=broadcom.com [at] lists [mailto:openstack-bounces+slogan=broadcom.com [at] lists] On Behalf Of Kyle Mestery (kmestery)
Sent: Wednesday, September 05, 2012 1:15 PM
To: OpenStack Development Mailing List
Cc: <openstack-operators [at] lists>; andi abes; <openstack [at] lists>
Subject: Re: [Openstack] [openstack-dev] Quantum vs. Nova-network in Folsom

On Sep 5, 2012, at 2:25 PM, Chris Wright wrote:
> * Dan Wendlandt (dan [at] nicira) wrote:
>> On Wed, Sep 5, 2012 at 5:23 AM, andi abes <andi.abes [at] gmail> wrote:
>>> late to the party... but I'll dabble.
>>>
>>> On Mon, Aug 27, 2012 at 12:21 PM, Chris Wright <chrisw [at] sous-sol> wrote:
>>>> * Rob_Hirschfeld [at] Dell (Rob_Hirschfeld [at] Dell) wrote:
>>>>> 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.
>>>>
>>>> To what end?
>>>
>>> OVS provides much more robust monitoring and operational facilities
>>> (e.g sFlow monitoring, better switch table visibility etc).
>>
>> You won't find any disagreement from me about OVS having more advanced
>> capabilities :)
>>
>>> It also provides a linux-bridge compatibility layer (ovs-brcompatd
>>> [1]), which should work out-of-box with the linux-bridge. As such,
>>> switching to using OVS rather than the linux bridge could be done
>>> without any code changes to nova, just deployment changes (e.g. ensure
>>> that ovs-brcompatd is running to intercept brctl ioctl's - [2]).
>>
>> Using ovs-brcompatd would be possible, though some distros do not
>> package and run it by default and in general it is not the "preferred"
>> way to run things according to email on the OVS mailing list.
>
> Indeed. While it's doable, it's not something that will hit upstream
> Linux, and therefore will not be supported by some distros.
>
> But, in general...while adding OVS support to nova networking (in the
> simplest layer 2 switch mode), may not be much work. It's adding a (not
> particularly useful) feature to a code base that we hope to deprecate.
> And making it more useful (adding things like tunnelling) support are
> really the point of Quantum.
>
I think that's what this really boils down to: The entire point of Quantum was to
add feature-rich networking as it's own service to OpenStack. Hedging by
adding piecemeal features to nova-net at this point may seem ok, but it's
a slippery slope, and may end up duplicating work which has already happened
in Quantum.

Thanks,
Kyle

> thanks,
> -chris
>
> _______________________________________________
> OpenStack-dev mailing list
> OpenStack-dev [at] lists
> http://lists.openstack.org/cgi-bin/mailman/listinfo/openstack-dev

_______________________________________________
Mailing list: https://launchpad.net/~openstack
Post to : openstack [at] lists
Unsubscribe : https://launchpad.net/~openstack
More help : https://help.launchpad.net/ListHelp

_______________________________________________
Mailing list: https://launchpad.net/~openstack
Post to : openstack [at] lists
Unsubscribe : https://launchpad.net/~openstack
More help : https://help.launchpad.net/ListHelp

andi.abes at gmail

Sep 5, 2012, 2:50 PM

Post #15 of 22 (2606 views)
Permalink

Re: Quantum vs. Nova-network in Folsom [In reply to]

On Wed, Sep 5, 2012 at 1:01 PM, Dan Wendlandt <dan [at] nicira> wrote:
> On Wed, Sep 5, 2012 at 5:23 AM, andi abes <andi.abes [at] gmail> wrote:
>> late to the party... but I'll dabble.
>>
>> On Mon, Aug 27, 2012 at 12:21 PM, Chris Wright <chrisw [at] sous-sol> wrote:
>>> * Rob_Hirschfeld [at] Dell (Rob_Hirschfeld [at] Dell) wrote:
>>>> 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.
>>>
>>> To what end?
>>
>> OVS provides much more robust monitoring and operational facilities
>> (e.g sFlow monitoring, better switch table visibility etc).
>
> You won't find any disagreement from me about OVS having more advanced
> capabilities :)
>
>> It also provides a linux-bridge compatibility layer (ovs-brcompatd
>> [1]), which should work out-of-box with the linux-bridge. As such,
>> switching to using OVS rather than the linux bridge could be done
>> without any code changes to nova, just deployment changes (e.g. ensure
>> that ovs-brcompatd is running to intercept brctl ioctl's - [2]).
>
> Using ovs-brcompatd would be possible, though some distros do not
> package and run it by default and in general it is not the "preferred"
> way to run things according to email on the OVS mailing list.
>
agreed this is providing minimal exposure to OVS capabilities. The
thought was that it would provide a path to:
* AVOID making ANY changes to nova-network, while still being able to use ovs
* this could allow Operators to obtain operational experience running
and monitoring ovs when its deployed in a somewhat degenerate
deployment.

>>
>> For the more adventurous, there could be any number of interesting
>> scenarios enabled by having access to ovs capabilities (e.g.
>> tunneling)
>
> Tunneling is definitely a huge benefit of OVS, but you still need
> someone to setup the tunnels and direct packets into them correctly.
> That's is exactly what the Quantum OVS plugin does and it is
> completely open source and freely available, so if people want to
> experiment with OVS tunneling, using Quantum would seem like the
> obvious way to do this.
>

true. but that would require moving on to quantum, with the associated pains.

> Dan
>
>

sorry if I stirred a fuss on a relatively dormant thread.

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

_______________________________________________
Mailing list: https://launchpad.net/~openstack
Post to : openstack [at] lists
Unsubscribe : https://launchpad.net/~openstack
More help : https://help.launchpad.net/ListHelp

mathieu.rohon at gmail

Sep 6, 2012, 12:50 AM

Post #16 of 22 (2603 views)
Permalink

Re: [openstack-dev] Quantum vs. Nova-network in Folsom [In reply to]

There is still the security filtering issue (
https://blueprints.launchpad.net/quantum/+spec/ovs-security-filtering)
which prevent some cloud operator from using OVS.

Do you have a workaround to use security group with OVS in folsom?

On Wed, Sep 5, 2012 at 7:01 PM, Dan Wendlandt <dan [at] nicira> wrote:

> On Wed, Sep 5, 2012 at 5:23 AM, andi abes <andi.abes [at] gmail> wrote:
> > late to the party... but I'll dabble.
> >
> > On Mon, Aug 27, 2012 at 12:21 PM, Chris Wright <chrisw [at] sous-sol>
> wrote:
> >> * Rob_Hirschfeld [at] Dell (Rob_Hirschfeld [at] Dell) wrote:
> >>> 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.
> >>
> >> To what end?
> >
> > OVS provides much more robust monitoring and operational facilities
> > (e.g sFlow monitoring, better switch table visibility etc).
>
> You won't find any disagreement from me about OVS having more advanced
> capabilities :)
>
> > It also provides a linux-bridge compatibility layer (ovs-brcompatd
> > [1]), which should work out-of-box with the linux-bridge. As such,
> > switching to using OVS rather than the linux bridge could be done
> > without any code changes to nova, just deployment changes (e.g. ensure
> > that ovs-brcompatd is running to intercept brctl ioctl's - [2]).
>
> Using ovs-brcompatd would be possible, though some distros do not
> package and run it by default and in general it is not the "preferred"
> way to run things according to email on the OVS mailing list.
>
> >
> > For the more adventurous, there could be any number of interesting
> > scenarios enabled by having access to ovs capabilities (e.g.
> > tunneling)
>
> Tunneling is definitely a huge benefit of OVS, but you still need
> someone to setup the tunnels and direct packets into them correctly.
> That's is exactly what the Quantum OVS plugin does and it is
> completely open source and freely available, so if people want to
> experiment with OVS tunneling, using Quantum would seem like the
> obvious way to do this.
>
> Dan
>
>
> --
> ~~~~~~~~~~~~~~~~~~~~~~~~~~~
> Dan Wendlandt
> Nicira, Inc: www.nicira.com
> twitter: danwendlandt
> ~~~~~~~~~~~~~~~~~~~~~~~~~~~
>
> _______________________________________________
> OpenStack-dev mailing list
> OpenStack-dev [at] lists
> http://lists.openstack.org/cgi-bin/mailman/listinfo/openstack-dev
>

dan at nicira

Sep 6, 2012, 9:29 AM

Post #17 of 22 (2607 views)
Permalink

Re: [openstack-dev] Quantum vs. Nova-network in Folsom [In reply to]

On Thu, Sep 6, 2012 at 12:50 AM, rohon mathieu <mathieu.rohon [at] gmail> wrote:
> There is still the security filtering issue
> (https://blueprints.launchpad.net/quantum/+spec/ovs-security-filtering)
> which prevent some cloud operator from using OVS.
>
> Do you have a workaround to use security group with OVS in folsom?

Yes, it merged into Nova yesterday.
https://bugs.launchpad.net/quantum/+bug/1039400

We're still working on the new Quantum docs for Folsom, but if you're
already familiar with using Quantum + Nova, the key difference is that
you use should a libvirt vif-plugging config of
LibvirtHybridOVSBridgeDriver, rather than just
LibvirtOpenVswitchDriver .

Dan

>
> On Wed, Sep 5, 2012 at 7:01 PM, Dan Wendlandt <dan [at] nicira> wrote:
>>
>> On Wed, Sep 5, 2012 at 5:23 AM, andi abes <andi.abes [at] gmail> wrote:
>> > late to the party... but I'll dabble.
>> >
>> > On Mon, Aug 27, 2012 at 12:21 PM, Chris Wright <chrisw [at] sous-sol>
>> > wrote:
>> >> * Rob_Hirschfeld [at] Dell (Rob_Hirschfeld [at] Dell) wrote:
>> >>> 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.
>> >>
>> >> To what end?
>> >
>> > OVS provides much more robust monitoring and operational facilities
>> > (e.g sFlow monitoring, better switch table visibility etc).
>>
>> You won't find any disagreement from me about OVS having more advanced
>> capabilities :)
>>
>> > It also provides a linux-bridge compatibility layer (ovs-brcompatd
>> > [1]), which should work out-of-box with the linux-bridge. As such,
>> > switching to using OVS rather than the linux bridge could be done
>> > without any code changes to nova, just deployment changes (e.g. ensure
>> > that ovs-brcompatd is running to intercept brctl ioctl's - [2]).
>>
>> Using ovs-brcompatd would be possible, though some distros do not
>> package and run it by default and in general it is not the "preferred"
>> way to run things according to email on the OVS mailing list.
>>
>> >
>> > For the more adventurous, there could be any number of interesting
>> > scenarios enabled by having access to ovs capabilities (e.g.
>> > tunneling)
>>
>> Tunneling is definitely a huge benefit of OVS, but you still need
>> someone to setup the tunnels and direct packets into them correctly.
>> That's is exactly what the Quantum OVS plugin does and it is
>> completely open source and freely available, so if people want to
>> experiment with OVS tunneling, using Quantum would seem like the
>> obvious way to do this.
>>
>> Dan
>>
>>
>> --
>> ~~~~~~~~~~~~~~~~~~~~~~~~~~~
>> Dan Wendlandt
>> Nicira, Inc: www.nicira.com
>> twitter: danwendlandt
>> ~~~~~~~~~~~~~~~~~~~~~~~~~~~
>>
>> _______________________________________________
>> OpenStack-dev mailing list
>> OpenStack-dev [at] lists
>> http://lists.openstack.org/cgi-bin/mailman/listinfo/openstack-dev
>
>
>
> _______________________________________________
> OpenStack-dev mailing list
> OpenStack-dev [at] lists
> http://lists.openstack.org/cgi-bin/mailman/listinfo/openstack-dev
>

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

_______________________________________________
Mailing list: https://launchpad.net/~openstack
Post to : openstack [at] lists
Unsubscribe : https://launchpad.net/~openstack
More help : https://help.launchpad.net/ListHelp

mathieu.rohon at gmail

Sep 7, 2012, 8:36 AM

Post #18 of 22 (2600 views)
Permalink

Re: [openstack-dev] Quantum vs. Nova-network in Folsom [In reply to]

great work thanks;

As you said the main missing feature of quantum is the multi-host L3-agent.
So I wonder if we can combine nova-network and quantum in a way that
nova-network is only used for L3 features?

On Thu, Sep 6, 2012 at 6:29 PM, Dan Wendlandt <dan [at] nicira> wrote:

> On Thu, Sep 6, 2012 at 12:50 AM, rohon mathieu <mathieu.rohon [at] gmail>
> wrote:
> > There is still the security filtering issue
> > (https://blueprints.launchpad.net/quantum/+spec/ovs-security-filtering)
> > which prevent some cloud operator from using OVS.
> >
> > Do you have a workaround to use security group with OVS in folsom?
>
> Yes, it merged into Nova yesterday.
> https://bugs.launchpad.net/quantum/+bug/1039400
>
> We're still working on the new Quantum docs for Folsom, but if you're
> already familiar with using Quantum + Nova, the key difference is that
> you use should a libvirt vif-plugging config of
> LibvirtHybridOVSBridgeDriver, rather than just
> LibvirtOpenVswitchDriver .
>
> Dan
>
>
>
>
>
> >
> > On Wed, Sep 5, 2012 at 7:01 PM, Dan Wendlandt <dan [at] nicira> wrote:
> >>
> >> On Wed, Sep 5, 2012 at 5:23 AM, andi abes <andi.abes [at] gmail> wrote:
> >> > late to the party... but I'll dabble.
> >> >
> >> > On Mon, Aug 27, 2012 at 12:21 PM, Chris Wright <chrisw [at] sous-sol>
> >> > wrote:
> >> >> * Rob_Hirschfeld [at] Dell (Rob_Hirschfeld [at] Dell) wrote:
> >> >>> 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.
> >> >>
> >> >> To what end?
> >> >
> >> > OVS provides much more robust monitoring and operational facilities
> >> > (e.g sFlow monitoring, better switch table visibility etc).
> >>
> >> You won't find any disagreement from me about OVS having more advanced
> >> capabilities :)
> >>
> >> > It also provides a linux-bridge compatibility layer (ovs-brcompatd
> >> > [1]), which should work out-of-box with the linux-bridge. As such,
> >> > switching to using OVS rather than the linux bridge could be done
> >> > without any code changes to nova, just deployment changes (e.g. ensure
> >> > that ovs-brcompatd is running to intercept brctl ioctl's - [2]).
> >>
> >> Using ovs-brcompatd would be possible, though some distros do not
> >> package and run it by default and in general it is not the "preferred"
> >> way to run things according to email on the OVS mailing list.
> >>
> >> >
> >> > For the more adventurous, there could be any number of interesting
> >> > scenarios enabled by having access to ovs capabilities (e.g.
> >> > tunneling)
> >>
> >> Tunneling is definitely a huge benefit of OVS, but you still need
> >> someone to setup the tunnels and direct packets into them correctly.
> >> That's is exactly what the Quantum OVS plugin does and it is
> >> completely open source and freely available, so if people want to
> >> experiment with OVS tunneling, using Quantum would seem like the
> >> obvious way to do this.
> >>
> >> Dan
> >>
> >>
> >> --
> >> ~~~~~~~~~~~~~~~~~~~~~~~~~~~
> >> Dan Wendlandt
> >> Nicira, Inc: www.nicira.com
> >> twitter: danwendlandt
> >> ~~~~~~~~~~~~~~~~~~~~~~~~~~~
> >>
> >> _______________________________________________
> >> OpenStack-dev mailing list
> >> OpenStack-dev [at] lists
> >> http://lists.openstack.org/cgi-bin/mailman/listinfo/openstack-dev
> >
> >
> >
> > _______________________________________________
> > OpenStack-dev mailing list
> > OpenStack-dev [at] lists
> > http://lists.openstack.org/cgi-bin/mailman/listinfo/openstack-dev
> >
>
>
>
> --
> ~~~~~~~~~~~~~~~~~~~~~~~~~~~
> Dan Wendlandt
> Nicira, Inc: www.nicira.com
> twitter: danwendlandt
> ~~~~~~~~~~~~~~~~~~~~~~~~~~~
>
> _______________________________________________
> OpenStack-dev mailing list
> OpenStack-dev [at] lists
> http://lists.openstack.org/cgi-bin/mailman/listinfo/openstack-dev
>

dan at nicira

Sep 7, 2012, 9:56 AM

Post #19 of 22 (2607 views)
Permalink

Re: [openstack-dev] Quantum vs. Nova-network in Folsom [In reply to]

On Fri, Sep 7, 2012 at 8:36 AM, rohon mathieu <mathieu.rohon [at] gmail> wrote:
> great work thanks;
>
> As you said the main missing feature of quantum is the multi-host L3-agent.
> So I wonder if we can combine nova-network and quantum in a way that
> nova-network is only used for L3 features?

I agree that it would be great if there was a simple work around like
that, but I think the core of the problem is the multi_host logic in
nova-network is closely tied to the IP Address Management (IPAM) logic
in nova. Quantum has its own IPAM logic, as it supports more advanced
scenarios like overlapping IP addresses on different networks. As a
result, I think trying to get the nova-network multi_host logic
working with Quantum would be on the same order of difficultly has
getting a multi_host equivalent working in Quantum. I don't think its
fundamentally hard, we just need to be spending our current Quantum
cycles on testing, bug fixing, and documentation and so had to drop
this feature for the Folsom release.

Dan

>
>
> On Thu, Sep 6, 2012 at 6:29 PM, Dan Wendlandt <dan [at] nicira> wrote:
>>
>> On Thu, Sep 6, 2012 at 12:50 AM, rohon mathieu <mathieu.rohon [at] gmail>
>> wrote:
>> > There is still the security filtering issue
>> > (https://blueprints.launchpad.net/quantum/+spec/ovs-security-filtering)
>> > which prevent some cloud operator from using OVS.
>> >
>> > Do you have a workaround to use security group with OVS in folsom?
>>
>> Yes, it merged into Nova yesterday.
>> https://bugs.launchpad.net/quantum/+bug/1039400
>>
>> We're still working on the new Quantum docs for Folsom, but if you're
>> already familiar with using Quantum + Nova, the key difference is that
>> you use should a libvirt vif-plugging config of
>> LibvirtHybridOVSBridgeDriver, rather than just
>> LibvirtOpenVswitchDriver .
>>
>> Dan
>>
>>
>>
>>
>>
>> >
>> > On Wed, Sep 5, 2012 at 7:01 PM, Dan Wendlandt <dan [at] nicira> wrote:
>> >>
>> >> On Wed, Sep 5, 2012 at 5:23 AM, andi abes <andi.abes [at] gmail> wrote:
>> >> > late to the party... but I'll dabble.
>> >> >
>> >> > On Mon, Aug 27, 2012 at 12:21 PM, Chris Wright <chrisw [at] sous-sol>
>> >> > wrote:
>> >> >> * Rob_Hirschfeld [at] Dell (Rob_Hirschfeld [at] Dell) wrote:
>> >> >>> 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.
>> >> >>
>> >> >> To what end?
>> >> >
>> >> > OVS provides much more robust monitoring and operational facilities
>> >> > (e.g sFlow monitoring, better switch table visibility etc).
>> >>
>> >> You won't find any disagreement from me about OVS having more advanced
>> >> capabilities :)
>> >>
>> >> > It also provides a linux-bridge compatibility layer (ovs-brcompatd
>> >> > [1]), which should work out-of-box with the linux-bridge. As such,
>> >> > switching to using OVS rather than the linux bridge could be done
>> >> > without any code changes to nova, just deployment changes (e.g.
>> >> > ensure
>> >> > that ovs-brcompatd is running to intercept brctl ioctl's - [2]).
>> >>
>> >> Using ovs-brcompatd would be possible, though some distros do not
>> >> package and run it by default and in general it is not the "preferred"
>> >> way to run things according to email on the OVS mailing list.
>> >>
>> >> >
>> >> > For the more adventurous, there could be any number of interesting
>> >> > scenarios enabled by having access to ovs capabilities (e.g.
>> >> > tunneling)
>> >>
>> >> Tunneling is definitely a huge benefit of OVS, but you still need
>> >> someone to setup the tunnels and direct packets into them correctly.
>> >> That's is exactly what the Quantum OVS plugin does and it is
>> >> completely open source and freely available, so if people want to
>> >> experiment with OVS tunneling, using Quantum would seem like the
>> >> obvious way to do this.
>> >>
>> >> Dan
>> >>
>> >>
>> >> --
>> >> ~~~~~~~~~~~~~~~~~~~~~~~~~~~
>> >> Dan Wendlandt
>> >> Nicira, Inc: www.nicira.com
>> >> twitter: danwendlandt
>> >> ~~~~~~~~~~~~~~~~~~~~~~~~~~~
>> >>
>> >> _______________________________________________
>> >> OpenStack-dev mailing list
>> >> OpenStack-dev [at] lists
>> >> http://lists.openstack.org/cgi-bin/mailman/listinfo/openstack-dev
>> >
>> >
>> >
>> > _______________________________________________
>> > OpenStack-dev mailing list
>> > OpenStack-dev [at] lists
>> > http://lists.openstack.org/cgi-bin/mailman/listinfo/openstack-dev
>> >
>>
>>
>>
>> --
>> ~~~~~~~~~~~~~~~~~~~~~~~~~~~
>> Dan Wendlandt
>> Nicira, Inc: www.nicira.com
>> twitter: danwendlandt
>> ~~~~~~~~~~~~~~~~~~~~~~~~~~~
>>
>> _______________________________________________
>> OpenStack-dev mailing list
>> OpenStack-dev [at] lists
>> http://lists.openstack.org/cgi-bin/mailman/listinfo/openstack-dev
>
>
>
> _______________________________________________
> OpenStack-dev mailing list
> OpenStack-dev [at] lists
> http://lists.openstack.org/cgi-bin/mailman/listinfo/openstack-dev
>

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

_______________________________________________
Mailing list: https://launchpad.net/~openstack
Post to : openstack [at] lists
Unsubscribe : https://launchpad.net/~openstack
More help : https://help.launchpad.net/ListHelp

slogan at broadcom

Sep 7, 2012, 10:34 AM

Post #20 of 22 (2607 views)
Permalink

Re: [openstack-dev] Quantum vs. Nova-network in Folsom [In reply to]

I'm I correct in believing that the Quantum L3 Abstractions and API Framework (https://blueprints.launchpad.net/quantum/+spec/quantum-l3-api) is the current plan of record for bringing L2toL3 functionality (e.g., VXLAN/NVGRE) into Quantum?

Is anyone signed up to do this or has this blueprint been deprecated in favor of some other approach?

Thanks,

syd

-----Original Message-----
From: openstack-bounces+slogan=broadcom.com [at] lists [mailto:openstack-bounces+slogan=broadcom.com [at] lists] On Behalf Of Dan Wendlandt
Sent: Friday, September 07, 2012 9:57 AM
To: OpenStack Development Mailing List
Cc: openstack-operators [at] lists; andi abes; openstack [at] lists
Subject: Re: [Openstack] [openstack-dev] Quantum vs. Nova-network in Folsom

On Fri, Sep 7, 2012 at 8:36 AM, rohon mathieu <mathieu.rohon [at] gmail> wrote:
> great work thanks;
>
> As you said the main missing feature of quantum is the multi-host L3-agent.
> So I wonder if we can combine nova-network and quantum in a way that
> nova-network is only used for L3 features?

I agree that it would be great if there was a simple work around like
that, but I think the core of the problem is the multi_host logic in
nova-network is closely tied to the IP Address Management (IPAM) logic
in nova. Quantum has its own IPAM logic, as it supports more advanced
scenarios like overlapping IP addresses on different networks. As a
result, I think trying to get the nova-network multi_host logic
working with Quantum would be on the same order of difficultly has
getting a multi_host equivalent working in Quantum. I don't think its
fundamentally hard, we just need to be spending our current Quantum
cycles on testing, bug fixing, and documentation and so had to drop
this feature for the Folsom release.

Dan

>
>
> On Thu, Sep 6, 2012 at 6:29 PM, Dan Wendlandt <dan [at] nicira> wrote:
>>
>> On Thu, Sep 6, 2012 at 12:50 AM, rohon mathieu <mathieu.rohon [at] gmail>
>> wrote:
>> > There is still the security filtering issue
>> > (https://blueprints.launchpad.net/quantum/+spec/ovs-security-filtering)
>> > which prevent some cloud operator from using OVS.
>> >
>> > Do you have a workaround to use security group with OVS in folsom?
>>
>> Yes, it merged into Nova yesterday.
>> https://bugs.launchpad.net/quantum/+bug/1039400
>>
>> We're still working on the new Quantum docs for Folsom, but if you're
>> already familiar with using Quantum + Nova, the key difference is that
>> you use should a libvirt vif-plugging config of
>> LibvirtHybridOVSBridgeDriver, rather than just
>> LibvirtOpenVswitchDriver .
>>
>> Dan
>>
>>
>>
>>
>>
>> >
>> > On Wed, Sep 5, 2012 at 7:01 PM, Dan Wendlandt <dan [at] nicira> wrote:
>> >>
>> >> On Wed, Sep 5, 2012 at 5:23 AM, andi abes <andi.abes [at] gmail> wrote:
>> >> > late to the party... but I'll dabble.
>> >> >
>> >> > On Mon, Aug 27, 2012 at 12:21 PM, Chris Wright <chrisw [at] sous-sol>
>> >> > wrote:
>> >> >> * Rob_Hirschfeld [at] Dell (Rob_Hirschfeld [at] Dell) wrote:
>> >> >>> 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.
>> >> >>
>> >> >> To what end?
>> >> >
>> >> > OVS provides much more robust monitoring and operational facilities
>> >> > (e.g sFlow monitoring, better switch table visibility etc).
>> >>
>> >> You won't find any disagreement from me about OVS having more advanced
>> >> capabilities :)
>> >>
>> >> > It also provides a linux-bridge compatibility layer (ovs-brcompatd
>> >> > [1]), which should work out-of-box with the linux-bridge. As such,
>> >> > switching to using OVS rather than the linux bridge could be done
>> >> > without any code changes to nova, just deployment changes (e.g.
>> >> > ensure
>> >> > that ovs-brcompatd is running to intercept brctl ioctl's - [2]).
>> >>
>> >> Using ovs-brcompatd would be possible, though some distros do not
>> >> package and run it by default and in general it is not the "preferred"
>> >> way to run things according to email on the OVS mailing list.
>> >>
>> >> >
>> >> > For the more adventurous, there could be any number of interesting
>> >> > scenarios enabled by having access to ovs capabilities (e.g.
>> >> > tunneling)
>> >>
>> >> Tunneling is definitely a huge benefit of OVS, but you still need
>> >> someone to setup the tunnels and direct packets into them correctly.
>> >> That's is exactly what the Quantum OVS plugin does and it is
>> >> completely open source and freely available, so if people want to
>> >> experiment with OVS tunneling, using Quantum would seem like the
>> >> obvious way to do this.
>> >>
>> >> Dan
>> >>
>> >>
>> >> --
>> >> ~~~~~~~~~~~~~~~~~~~~~~~~~~~
>> >> Dan Wendlandt
>> >> Nicira, Inc: www.nicira.com
>> >> twitter: danwendlandt
>> >> ~~~~~~~~~~~~~~~~~~~~~~~~~~~
>> >>
>> >> _______________________________________________
>> >> OpenStack-dev mailing list
>> >> OpenStack-dev [at] lists
>> >> http://lists.openstack.org/cgi-bin/mailman/listinfo/openstack-dev
>> >
>> >
>> >
>> > _______________________________________________
>> > OpenStack-dev mailing list
>> > OpenStack-dev [at] lists
>> > http://lists.openstack.org/cgi-bin/mailman/listinfo/openstack-dev
>> >
>>
>>
>>
>> --
>> ~~~~~~~~~~~~~~~~~~~~~~~~~~~
>> Dan Wendlandt
>> Nicira, Inc: www.nicira.com
>> twitter: danwendlandt
>> ~~~~~~~~~~~~~~~~~~~~~~~~~~~
>>
>> _______________________________________________
>> OpenStack-dev mailing list
>> OpenStack-dev [at] lists
>> http://lists.openstack.org/cgi-bin/mailman/listinfo/openstack-dev
>
>
>
> _______________________________________________
> OpenStack-dev mailing list
> OpenStack-dev [at] lists
> http://lists.openstack.org/cgi-bin/mailman/listinfo/openstack-dev
>

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

_______________________________________________
Mailing list: https://launchpad.net/~openstack
Post to : openstack [at] lists
Unsubscribe : https://launchpad.net/~openstack
More help : https://help.launchpad.net/ListHelp

_______________________________________________
Mailing list: https://launchpad.net/~openstack
Post to : openstack [at] lists
Unsubscribe : https://launchpad.net/~openstack
More help : https://help.launchpad.net/ListHelp

dan at nicira

Sep 7, 2012, 11:11 AM

Post #21 of 22 (2607 views)
Permalink

Re: [openstack-dev] Quantum vs. Nova-network in Folsom [In reply to]

Hi Syd,

On Fri, Sep 7, 2012 at 10:34 AM, Syd (Sydney) Logan <slogan [at] broadcom> wrote:
> I'm I correct in believing that the Quantum L3 Abstractions and API Framework (https://blueprints.launchpad.net/quantum/+spec/quantum-l3-api) is the current plan of record for bringing L2toL3 functionality (e.g., VXLAN/NVGRE) into Quantum?

Several Quantum plugins already have L3-over-L3 "overlay" tunneling
capability to provide private L2 tenant networks without VLANs. These
plugins include the Open vSwitch plugin (completely free/open source)
and the Nicira NVP plugin (commercial). I suspect others will add
this capability as well in the future, and in general its a great
example of the new network technologies that Quantum enables.

The blueprint above is actually complete and merged, but is actually
about letting tenants define "routers" that connect multiple L2
Quantum networks (e.g., to make multi-tier web applications). These
routers can also provide access to external networks and implement
floating IPs. We're still wrapping up the Folsom Quantum docs, but
hopefully this capability will be more clear soon. Thanks,

Dan

>
> Is anyone signed up to do this or has this blueprint been deprecated in favor of some other approach?
>
> Thanks,
>
> syd
>
> -----Original Message-----
> From: openstack-bounces+slogan=broadcom.com [at] lists [mailto:openstack-bounces+slogan=broadcom.com [at] lists] On Behalf Of Dan Wendlandt
> Sent: Friday, September 07, 2012 9:57 AM
> To: OpenStack Development Mailing List
> Cc: openstack-operators [at] lists; andi abes; openstack [at] lists
> Subject: Re: [Openstack] [openstack-dev] Quantum vs. Nova-network in Folsom
>
> On Fri, Sep 7, 2012 at 8:36 AM, rohon mathieu <mathieu.rohon [at] gmail> wrote:
>> great work thanks;
>>
>> As you said the main missing feature of quantum is the multi-host L3-agent.
>> So I wonder if we can combine nova-network and quantum in a way that
>> nova-network is only used for L3 features?
>
> I agree that it would be great if there was a simple work around like
> that, but I think the core of the problem is the multi_host logic in
> nova-network is closely tied to the IP Address Management (IPAM) logic
> in nova. Quantum has its own IPAM logic, as it supports more advanced
> scenarios like overlapping IP addresses on different networks. As a
> result, I think trying to get the nova-network multi_host logic
> working with Quantum would be on the same order of difficultly has
> getting a multi_host equivalent working in Quantum. I don't think its
> fundamentally hard, we just need to be spending our current Quantum
> cycles on testing, bug fixing, and documentation and so had to drop
> this feature for the Folsom release.
>
> Dan
>
>
>
>>
>>
>> On Thu, Sep 6, 2012 at 6:29 PM, Dan Wendlandt <dan [at] nicira> wrote:
>>>
>>> On Thu, Sep 6, 2012 at 12:50 AM, rohon mathieu <mathieu.rohon [at] gmail>
>>> wrote:
>>> > There is still the security filtering issue
>>> > (https://blueprints.launchpad.net/quantum/+spec/ovs-security-filtering)
>>> > which prevent some cloud operator from using OVS.
>>> >
>>> > Do you have a workaround to use security group with OVS in folsom?
>>>
>>> Yes, it merged into Nova yesterday.
>>> https://bugs.launchpad.net/quantum/+bug/1039400
>>>
>>> We're still working on the new Quantum docs for Folsom, but if you're
>>> already familiar with using Quantum + Nova, the key difference is that
>>> you use should a libvirt vif-plugging config of
>>> LibvirtHybridOVSBridgeDriver, rather than just
>>> LibvirtOpenVswitchDriver .
>>>
>>> Dan
>>>
>>>
>>>
>>>
>>>
>>> >
>>> > On Wed, Sep 5, 2012 at 7:01 PM, Dan Wendlandt <dan [at] nicira> wrote:
>>> >>
>>> >> On Wed, Sep 5, 2012 at 5:23 AM, andi abes <andi.abes [at] gmail> wrote:
>>> >> > late to the party... but I'll dabble.
>>> >> >
>>> >> > On Mon, Aug 27, 2012 at 12:21 PM, Chris Wright <chrisw [at] sous-sol>
>>> >> > wrote:
>>> >> >> * Rob_Hirschfeld [at] Dell (Rob_Hirschfeld [at] Dell) wrote:
>>> >> >>> 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.
>>> >> >>
>>> >> >> To what end?
>>> >> >
>>> >> > OVS provides much more robust monitoring and operational facilities
>>> >> > (e.g sFlow monitoring, better switch table visibility etc).
>>> >>
>>> >> You won't find any disagreement from me about OVS having more advanced
>>> >> capabilities :)
>>> >>
>>> >> > It also provides a linux-bridge compatibility layer (ovs-brcompatd
>>> >> > [1]), which should work out-of-box with the linux-bridge. As such,
>>> >> > switching to using OVS rather than the linux bridge could be done
>>> >> > without any code changes to nova, just deployment changes (e.g.
>>> >> > ensure
>>> >> > that ovs-brcompatd is running to intercept brctl ioctl's - [2]).
>>> >>
>>> >> Using ovs-brcompatd would be possible, though some distros do not
>>> >> package and run it by default and in general it is not the "preferred"
>>> >> way to run things according to email on the OVS mailing list.
>>> >>
>>> >> >
>>> >> > For the more adventurous, there could be any number of interesting
>>> >> > scenarios enabled by having access to ovs capabilities (e.g.
>>> >> > tunneling)
>>> >>
>>> >> Tunneling is definitely a huge benefit of OVS, but you still need
>>> >> someone to setup the tunnels and direct packets into them correctly.
>>> >> That's is exactly what the Quantum OVS plugin does and it is
>>> >> completely open source and freely available, so if people want to
>>> >> experiment with OVS tunneling, using Quantum would seem like the
>>> >> obvious way to do this.
>>> >>
>>> >> Dan
>>> >>
>>> >>
>>> >> --
>>> >> ~~~~~~~~~~~~~~~~~~~~~~~~~~~
>>> >> Dan Wendlandt
>>> >> Nicira, Inc: www.nicira.com
>>> >> twitter: danwendlandt
>>> >> ~~~~~~~~~~~~~~~~~~~~~~~~~~~
>>> >>
>>> >> _______________________________________________
>>> >> OpenStack-dev mailing list
>>> >> OpenStack-dev [at] lists
>>> >> http://lists.openstack.org/cgi-bin/mailman/listinfo/openstack-dev
>>> >
>>> >
>>> >
>>> > _______________________________________________
>>> > OpenStack-dev mailing list
>>> > OpenStack-dev [at] lists
>>> > http://lists.openstack.org/cgi-bin/mailman/listinfo/openstack-dev
>>> >
>>>
>>>
>>>
>>> --
>>> ~~~~~~~~~~~~~~~~~~~~~~~~~~~
>>> Dan Wendlandt
>>> Nicira, Inc: www.nicira.com
>>> twitter: danwendlandt
>>> ~~~~~~~~~~~~~~~~~~~~~~~~~~~
>>>
>>> _______________________________________________
>>> OpenStack-dev mailing list
>>> OpenStack-dev [at] lists
>>> http://lists.openstack.org/cgi-bin/mailman/listinfo/openstack-dev
>>
>>
>>
>> _______________________________________________
>> OpenStack-dev mailing list
>> OpenStack-dev [at] lists
>> http://lists.openstack.org/cgi-bin/mailman/listinfo/openstack-dev
>>
>
>
>
> --
> ~~~~~~~~~~~~~~~~~~~~~~~~~~~
> Dan Wendlandt
> Nicira, Inc: www.nicira.com
> twitter: danwendlandt
> ~~~~~~~~~~~~~~~~~~~~~~~~~~~
>
> _______________________________________________
> Mailing list: https://launchpad.net/~openstack
> Post to : openstack [at] lists
> 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 : openstack [at] lists
Unsubscribe : https://launchpad.net/~openstack
More help : https://help.launchpad.net/ListHelp

slogan at broadcom

Sep 7, 2012, 12:02 PM

Post #22 of 22 (2620 views)
Permalink

Re: [openstack-dev] Quantum vs. Nova-network in Folsom [In reply to]

I've observed and studied the OVS L3oL3 tunneling in a multi-node configuration with F3 by packet sniffing VM to VM pings, and have a basic understanding about how the mesh of tunnels comes into existence. Pretty cool.

Guessing https://github.com/openstack/quantum/commit/3005d16fe3588bdf4b928e79f640b991df9fae3b is the merge you are referring to that implements the blueprint. There was also a link to a quantum fork created by CISCO that was mentioned in the blueprint, not sure how the code relates (I'm reading both right now).

How this ties in with VXLAN and NVGRE (which I guessed from the blueprint both would be plugin instances) is still a bit of a mystery to me, so I look forward to whatever documentation appears.

Thanks,

syd

-----Original Message-----
From: Dan Wendlandt [mailto:dan [at] nicira]
Sent: Friday, September 07, 2012 11:11 AM
To: Syd (Sydney) Logan
Cc: OpenStack Development Mailing List; openstack-operators [at] lists; andi abes; openstack [at] lists
Subject: Re: [Openstack] [openstack-dev] Quantum vs. Nova-network in Folsom

Hi Syd,

On Fri, Sep 7, 2012 at 10:34 AM, Syd (Sydney) Logan <slogan [at] broadcom> wrote:
> I'm I correct in believing that the Quantum L3 Abstractions and API Framework (https://blueprints.launchpad.net/quantum/+spec/quantum-l3-api) is the current plan of record for bringing L2toL3 functionality (e.g., VXLAN/NVGRE) into Quantum?

Several Quantum plugins already have L3-over-L3 "overlay" tunneling
capability to provide private L2 tenant networks without VLANs. These
plugins include the Open vSwitch plugin (completely free/open source)
and the Nicira NVP plugin (commercial). I suspect others will add
this capability as well in the future, and in general its a great
example of the new network technologies that Quantum enables.

The blueprint above is actually complete and merged, but is actually
about letting tenants define "routers" that connect multiple L2
Quantum networks (e.g., to make multi-tier web applications). These
routers can also provide access to external networks and implement
floating IPs. We're still wrapping up the Folsom Quantum docs, but
hopefully this capability will be more clear soon. Thanks,

Dan

>
> Is anyone signed up to do this or has this blueprint been deprecated in favor of some other approach?
>
> Thanks,
>
> syd
>
> -----Original Message-----
> From: openstack-bounces+slogan=broadcom.com [at] lists [mailto:openstack-bounces+slogan=broadcom.com [at] lists] On Behalf Of Dan Wendlandt
> Sent: Friday, September 07, 2012 9:57 AM
> To: OpenStack Development Mailing List
> Cc: openstack-operators [at] lists; andi abes; openstack [at] lists
> Subject: Re: [Openstack] [openstack-dev] Quantum vs. Nova-network in Folsom
>
> On Fri, Sep 7, 2012 at 8:36 AM, rohon mathieu <mathieu.rohon [at] gmail> wrote:
>> great work thanks;
>>
>> As you said the main missing feature of quantum is the multi-host L3-agent.
>> So I wonder if we can combine nova-network and quantum in a way that
>> nova-network is only used for L3 features?
>
> I agree that it would be great if there was a simple work around like
> that, but I think the core of the problem is the multi_host logic in
> nova-network is closely tied to the IP Address Management (IPAM) logic
> in nova. Quantum has its own IPAM logic, as it supports more advanced
> scenarios like overlapping IP addresses on different networks. As a
> result, I think trying to get the nova-network multi_host logic
> working with Quantum would be on the same order of difficultly has
> getting a multi_host equivalent working in Quantum. I don't think its
> fundamentally hard, we just need to be spending our current Quantum
> cycles on testing, bug fixing, and documentation and so had to drop
> this feature for the Folsom release.
>
> Dan
>
>
>
>>
>>
>> On Thu, Sep 6, 2012 at 6:29 PM, Dan Wendlandt <dan [at] nicira> wrote:
>>>
>>> On Thu, Sep 6, 2012 at 12:50 AM, rohon mathieu <mathieu.rohon [at] gmail>
>>> wrote:
>>> > There is still the security filtering issue
>>> > (https://blueprints.launchpad.net/quantum/+spec/ovs-security-filtering)
>>> > which prevent some cloud operator from using OVS.
>>> >
>>> > Do you have a workaround to use security group with OVS in folsom?
>>>
>>> Yes, it merged into Nova yesterday.
>>> https://bugs.launchpad.net/quantum/+bug/1039400
>>>
>>> We're still working on the new Quantum docs for Folsom, but if you're
>>> already familiar with using Quantum + Nova, the key difference is that
>>> you use should a libvirt vif-plugging config of
>>> LibvirtHybridOVSBridgeDriver, rather than just
>>> LibvirtOpenVswitchDriver .
>>>
>>> Dan
>>>
>>>
>>>
>>>
>>>
>>> >
>>> > On Wed, Sep 5, 2012 at 7:01 PM, Dan Wendlandt <dan [at] nicira> wrote:
>>> >>
>>> >> On Wed, Sep 5, 2012 at 5:23 AM, andi abes <andi.abes [at] gmail> wrote:
>>> >> > late to the party... but I'll dabble.
>>> >> >
>>> >> > On Mon, Aug 27, 2012 at 12:21 PM, Chris Wright <chrisw [at] sous-sol>
>>> >> > wrote:
>>> >> >> * Rob_Hirschfeld [at] Dell (Rob_Hirschfeld [at] Dell) wrote:
>>> >> >>> 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.
>>> >> >>
>>> >> >> To what end?
>>> >> >
>>> >> > OVS provides much more robust monitoring and operational facilities
>>> >> > (e.g sFlow monitoring, better switch table visibility etc).
>>> >>
>>> >> You won't find any disagreement from me about OVS having more advanced
>>> >> capabilities :)
>>> >>
>>> >> > It also provides a linux-bridge compatibility layer (ovs-brcompatd
>>> >> > [1]), which should work out-of-box with the linux-bridge. As such,
>>> >> > switching to using OVS rather than the linux bridge could be done
>>> >> > without any code changes to nova, just deployment changes (e.g.
>>> >> > ensure
>>> >> > that ovs-brcompatd is running to intercept brctl ioctl's - [2]).
>>> >>
>>> >> Using ovs-brcompatd would be possible, though some distros do not
>>> >> package and run it by default and in general it is not the "preferred"
>>> >> way to run things according to email on the OVS mailing list.
>>> >>
>>> >> >
>>> >> > For the more adventurous, there could be any number of interesting
>>> >> > scenarios enabled by having access to ovs capabilities (e.g.
>>> >> > tunneling)
>>> >>
>>> >> Tunneling is definitely a huge benefit of OVS, but you still need
>>> >> someone to setup the tunnels and direct packets into them correctly.
>>> >> That's is exactly what the Quantum OVS plugin does and it is
>>> >> completely open source and freely available, so if people want to
>>> >> experiment with OVS tunneling, using Quantum would seem like the
>>> >> obvious way to do this.
>>> >>
>>> >> Dan
>>> >>
>>> >>
>>> >> --
>>> >> ~~~~~~~~~~~~~~~~~~~~~~~~~~~
>>> >> Dan Wendlandt
>>> >> Nicira, Inc: www.nicira.com
>>> >> twitter: danwendlandt
>>> >> ~~~~~~~~~~~~~~~~~~~~~~~~~~~
>>> >>
>>> >> _______________________________________________
>>> >> OpenStack-dev mailing list
>>> >> OpenStack-dev [at] lists
>>> >> http://lists.openstack.org/cgi-bin/mailman/listinfo/openstack-dev
>>> >
>>> >
>>> >
>>> > _______________________________________________
>>> > OpenStack-dev mailing list
>>> > OpenStack-dev [at] lists
>>> > http://lists.openstack.org/cgi-bin/mailman/listinfo/openstack-dev
>>> >
>>>
>>>
>>>
>>> --
>>> ~~~~~~~~~~~~~~~~~~~~~~~~~~~
>>> Dan Wendlandt
>>> Nicira, Inc: www.nicira.com
>>> twitter: danwendlandt
>>> ~~~~~~~~~~~~~~~~~~~~~~~~~~~
>>>
>>> _______________________________________________
>>> OpenStack-dev mailing list
>>> OpenStack-dev [at] lists
>>> http://lists.openstack.org/cgi-bin/mailman/listinfo/openstack-dev
>>
>>
>>
>> _______________________________________________
>> OpenStack-dev mailing list
>> OpenStack-dev [at] lists
>> http://lists.openstack.org/cgi-bin/mailman/listinfo/openstack-dev
>>
>
>
>
> --
> ~~~~~~~~~~~~~~~~~~~~~~~~~~~
> Dan Wendlandt
> Nicira, Inc: www.nicira.com
> twitter: danwendlandt
> ~~~~~~~~~~~~~~~~~~~~~~~~~~~
>
> _______________________________________________
> Mailing list: https://launchpad.net/~openstack
> Post to : openstack [at] lists
> 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 : openstack [at] lists
Unsubscribe : https://launchpad.net/~openstack
More help : https://help.launchpad.net/ListHelp

Index | Next | Previous | View Threaded

Interested in having your list archived? Contact Gossamer Threads