openstack team mailing list archive

[Dan Wendlandt <dan@xxxxxxxxxx>]

On Thu, Sep 6, 2012 at 12:50 AM, rohon mathieu <mathieu.rohon@xxxxxxxxx> 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@xxxxxxxxxx> wrote:
>>
>> On Wed, Sep 5, 2012 at 5:23 AM, andi abes <andi.abes@xxxxxxxxx> wrote:
>> > late to the party... but I'll dabble.
>> >
>> > On Mon, Aug 27, 2012 at 12:21 PM, Chris Wright <chrisw@xxxxxxxxxxxx>
>> > wrote:
>> >> * Rob_Hirschfeld@xxxxxxxx (Rob_Hirschfeld@xxxxxxxx) 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@xxxxxxxxxxxxxxxxxxx
>> http://lists.openstack.org/cgi-bin/mailman/listinfo/openstack-dev
>
>
>
> _______________________________________________
> OpenStack-dev mailing list
> OpenStack-dev@xxxxxxxxxxxxxxxxxxx
> http://lists.openstack.org/cgi-bin/mailman/listinfo/openstack-dev
>



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