openstack team mailing list archive

[Dan Wendlandt <dan@xxxxxxxxxx>]

On Fri, Dec 9, 2011 at 5:22 AM, Isaku Yamahata <yamahata@xxxxxxxxxxxxx>wrote:

> 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?
>

Hi Yamahata,

Oh, definitely.  I really should have set "create a blueprint and target it
as essex-3 as a place-holder".  We'll definitely need to talk through the
design first (though we probably don't need to flood the entire OS
community with such detailed discussions, so we can move it to the netstack
list).


>
> - 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.
>

I haven't looked at the entire patch yet, but yes, we'll have to figure out
how to handle different capabilities in the agent.  I know of others doing
similar things, so coming up with a pattern for this will be valuable.


>
> - 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?
>


I think the order above is incorrect.  If you look in
nova/compute/manager.py's _run_instance() method, the allocate_network()
call is called before _spawn(), which IIRC means that Quantum will be
called and the port created + attached before the VM port is created on OVS
or the VM is started.  So I don't think there's a fundamental ordering
problem.  It may just be that the polling period in the OVS agent needs to
be tuned down.  I've been thinking about splitting the logic that spots a
port and putting it in a separate thread with a shorter polling interval,
which may help.  Or it may be a bug that you're seeing :)


>
>
> > 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.
>

Yeah, that made sense.  I was more talking about some of the tweaks you did
to enable metadata + and general L3 forwarding in QuantumManager.  Brad had
a blueprint on that part fo the code that went in a week or so ago.

Dan



>
> 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
>



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