openstack team mailing list archive

[Isaku Yamahata <yamahata@xxxxxxxxxxxxx>]

On Fri, Dec 09, 2011 at 03:31:22AM -0800, Dan Wendlandt wrote:
> Hi, this is a neat project, thanks for sending it out.  

Hi.


> I'm really happy to see that you've already performed the Quantum integration
> by extending the Open vSwitch plugin.  This work is a great example of how
> Quantum can be used to plug in a variety of different back-end networking 
> technologies.   
> 
> Going through the docs, everything make sense.  Hopefully you can help
> contribute some of those graphics to the main Quantum documentation as well, as
> that's an area where our current docs are sorely lacking :) 
> 
> We can definitely help you get your extensions to the Quantum code into trunk,
> probably during the essex-3 timeframe (the essex-2 release is currently less
> than a week away, and is already locked down).   I would suggest creating a
> blueprint for this on http://launchpad.net/quantum .  If you have detailed
> questions about Quantum, you can send them to netstack@xxxxxxxxxxxxxxxxxxx .  
Okay, I'll create a blue print. Though, can we discuss on its design
beforehand?

- introduce OVS driver/OVS agent driver
  I think, there can be several kind of openflow controllers, so this is
  reasonable.
  The code refactoring and new options would be easily merged, I hope.

- window between port creation and port becoming usable.
  Currently, there is a window that VM can't connect to the network.

  1. ovs port creation by nova-compute virt-driver
  2. nova-compute call nova-network which calls quantum rest API
  3. instance creation and guest VM starts.
     the VM can't send/receive until OVS agent finds the port.
  4. ovs agent polls on compute node, and make the port available.

  I'd like to fix the window. nova-network doesn't have informations enough.
  So the possible options is
  - have nova-compute call quantum API, or
  - have nova-compute pass more information (maybe libvirt_vif_driver
    specific) as rpc argument to nova-network
  Maybe the first option would make the code simple, but it breaks the
  boundary between compute and netowrk. So my preference is the second option.
  Or any other ideas?


> It also looks like you have some small nova changes, mostly around the
> QuantumManager + OVS vif-plugging.  I think some of them may not be necessary 
> after some work done by brad in essex-2 around integrating QuantumManager with
> L3 + NAT (recently merged into trunk), but we can help figure that out as well.

The new firewall driver and network interface driver we introduced are
for demonstration making the point clear.
Nop firewall driver is introduced in order to show that the packet filtering
is done by Ryu, not by iptables.
If iptables firewall driver is enabled, it doesn't harm, it's just bypassed.

thanks,


>  
> 
> Dan 
> 
> 
> On Fri, Dec 9, 2011 at 1:52 AM, FUJITA Tomonori <fujita.tomonori@xxxxxxxxxxxxx>
> wrote:
> 
>     Hi all,
> 
>     We are glad to announce the Ryu open-sourced Network Operating System.
>     Ryu is released under GPL v3 license. It's fully written in Python.
> 
>     http://www.osrg.net/ryu/
> 
>     The project goal is to develop an OSS Network Operating System that
>     has high quality enough for use in large production environment in
>     code quality/functionality/usability.
> 
>     Ryu aims to provide a logically centralized control and well defined
>     API that make it easy for operators to create new network management
>     and control applications. Currently, Ryu supports OpenFlow protocol to
>     modify the behavior of network devices.
> 
>     We aim at the de facto OSS NOS implementation and NOS API.
> 
>     Currently, Ryu is shipped with one control application for OpenStack
>     network management L2 segregation of tenants without using VLAN. The
>     application includes the changes to OpenStack (nova, quantum ovs
>     plugin, etc).
> 
>     We are still in an early stage of development. Currently, Ryu is just
>     an OpenFlow Controller. There are lots of TODO items: OpenFlow
>     Protocol version 1.2 support (timely manner), the better API for
>     control applications, distributed store support, etc. Please join the
>     development community!
> 
>     Get source code:
> 
>     % git clone git://github.com/osrg/ryu.git
> 
>     Then just type:
> 
>     % cd ryu; python ./setup.py install
> 
>     and run ryu-manager command which is installed. Then set up your
>     OpenFlow switch (hardware switch or OVS) to connect the ip address and
>     port to which ryu-manager is listening.
> 
> 
>     =
>     NTT Cyber Space Laboratories
>     Open Source Software Computing Project
> 
>     FUJITA Tomonori
> 
>     _______________________________________________
>     Mailing list: https://launchpad.net/~openstack
>     Post to     : openstack@xxxxxxxxxxxxxxxxxxx
>     Unsubscribe : https://launchpad.net/~openstack
>     More help   : https://help.launchpad.net/ListHelp
> 
> 
> 
> 
> --
> ~~~~~~~~~~~~~~~~~~~~~~~~~~~
> Dan Wendlandt 
> Nicira Networks: www.nicira.com
> twitter: danwendlandt
> ~~~~~~~~~~~~~~~~~~~~~~~~~~~
> 

> _______________________________________________
> Mailing list: https://launchpad.net/~openstack
> Post to     : openstack@xxxxxxxxxxxxxxxxxxx
> Unsubscribe : https://launchpad.net/~openstack
> More help   : https://help.launchpad.net/ListHelp


-- 
yamahata