Re: [Netstack] [Openstack] [ANNOUNCE] Ryu OSS Network Operating System
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@lists.launchpad.net . 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 > > 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 : openst...@lists.launchpad.net > Unsubscribe : https://launchpad.net/~openstack > More help : https://help.launchpad.net/ListHelp > > > > > -- > ~~~ > Dan Wendlandt > Nicira Networks: www.nicira.com
Re: [Netstack] [Openstack] [ANNOUNCE] Ryu OSS Network Operating System
On Fri, Dec 09, 2011 at 09:02:09AM -0800, Dan Wendlandt wrote: > 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). Okay. > - 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 :) The polling period is the window. Shortening the interval make the window small, but never eliminates it. I'd like to make the agent work done before staring instance. > > 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. I see. I'll have a look at the blue print. -- yamahata -- Mailing list: https://launchpad.net/~netstack Post to : netstack@lists.launchpad.net Unsubscribe : https://launchpad.net/~netstack More help : https://help.launchpad.net/ListHelp
Re: [Netstack] [Ryu-devel] [Openstack] [ANNOUNCE] Ryu OSS Network Operating System
On Fri, Dec 09, 2011 at 09:02:09AM -0800, Dan Wendlandt wrote: > 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. I registered the blueprint. https://blueprints.launchpad.net/quantum/+spec/ovs-driver-extension Other discussion point is how to pass driver-specific parameters to OVS agent. passing parameters to OVS agent The current implementation uses ovs_quantum_plugin.ini on each compute-node. Maybe there are several options. My preference is the option B. A. All parameters in ovs_quantum_plugin.ini for ovs agent Each ovs_quantum_plugin.ini in compute-node has all necessary parameters. The administrator must guarantee all of them are consistent. B. ovs_quantum_plugin.ini in quantum server. ovs_quantum_plugin.ini for ovs agent only have [DATABASE] section and OVS:integration-bridge. Other options which would be commont to drivers or specific to each driver are passed to quantum-server, and stored in DB table. Each agent get those parameters from DB C. Other ideas thanks, -- yamahata -- Mailing list: https://launchpad.net/~netstack Post to : netstack@lists.launchpad.net Unsubscribe : https://launchpad.net/~netstack More help : https://help.launchpad.net/ListHelp
Re: [Netstack] Quantum Manager fails to delete networks
On Mon, Dec 12, 2011 at 08:21:12AM -0800, Dan Wendlandt wrote: > I believe the real issue is that QuantumManager needs to clean up the > "gateway" > port on a Quantum network before attempting to delete it, otherwise Quantum > refuses to to delete the network with a NetworkInUse error. This should be a > QuantumManager fix. Yes, it's QuantumManger that needs fixing. At the same time, dnsmasq corresponding to the "gateway" should be killed. -- yamahata -- Mailing list: https://launchpad.net/~netstack Post to : netstack@lists.launchpad.net Unsubscribe : https://launchpad.net/~netstack More help : https://help.launchpad.net/ListHelp
Re: [Netstack] Ryu support in Quantum
On Tue, Jan 10, 2012 at 09:13:33AM -0800, Dan Wendlandt wrote: > [ narrowing scope to netstack list, as there are more design discussion ] > > Hi Yamahata, Hi. > Since Essex-3 is now near, I wanted to touch based with you again about this. > > With respect to your thoughts below about "driver-specific" configuration. I > think it is fine for your code to store configuration in the DB, if you > prefer. > It is also possible to have different versions of the OVS plugin use > different > versions of the ini file. Either way, I think the goal of avoiding a single > global conf file with many driver-specific configuration options is avoided. Thank you for the comment. So it is agreed that the basic direction is okay. > Also, thank you for registering a blueprint. To get the code merged into > Quantum, you will need to propose a diff for review following the standard > OpenStack development process (see: http://wiki.openstack.org/GerritWorkflow). > > > Given that this looks like a pretty big patch, you should do this very soon if > you would like this to be part of the Essex-3 release (code freeze date is two > weeks away, but big patches from someone new to the project should be > proposed > well in advance of the code freeze to make sure all review comments can be > addressed). Otherwise, we should be able to get this in during the Essex-4 > cycle, so it will still make the main Essex release. Please do me a favor and > update the blueprint indicating whether you are planning on working on this > for > Essex-3. I delayed it to Essex-4 as the patch needs clean up and improvement. So I think it would be difficult to make it at Essex-3. > Thanks, > > Dan > > > On Sun, Dec 11, 2011 at 6:32 PM, Isaku Yamahata > wrote: > > On Fri, Dec 09, 2011 at 09:02:09AM -0800, Dan Wendlandt wrote: > > 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. > > I registered the blueprint. > https://blueprints.launchpad.net/quantum/+spec/ovs-driver-extension > > Other discussion point is how to pass driver-specific parameters to OVS > agent. > > passing parameters to OVS agent > The current implementation uses ovs_quantum_plugin.ini on each > compute-node. > Maybe there are several options. My preference is the option B. > > A. All parameters in ovs_quantum_plugin.ini for ovs agent >Each ovs_quantum_plugin.ini in compute-node has all necessary > parameters. >The administrator must guarantee all of them are consistent. > > B. ovs_quantum_plugin.ini in quantum server. > ovs_quantum_plugin.ini for ovs agent only have [DATABASE] section and > OVS:integration-bridge. > Other options which would be commont to drivers or specific to each > driver > are passed to quantum-server, and stored in DB table. > Each agent get those parameters from DB > > C. Other ideas > > > thanks, > -- > yamahata > > > > > -- > ~~~ > Dan Wendlandt > Nicira Networks: www.nicira.com > twitter: danwendlandt > ~~~ > -- yamahata -- Mailing list: https://launchpad.net/~netstack Post to : netstack@lists.launchpad.net Unsubscribe : https://launchpad.net/~netstack More help : https://help.launchpad.net/ListHelp
Re: [Netstack] Ryu support in Quantum
On Wed, Jan 11, 2012 at 11:15:03AM +0900, Isaku Yamahata wrote: > > Also, thank you for registering a blueprint. To get the code merged into > > Quantum, you will need to propose a diff for review following the standard > > OpenStack development process (see: > > http://wiki.openstack.org/GerritWorkflow). > > > > > > Given that this looks like a pretty big patch, you should do this very soon > > if > > you would like this to be part of the Essex-3 release (code freeze date is > > two > > weeks away, but big patches from someone new to the project should be > > proposed > > well in advance of the code freeze to make sure all review comments can be > > addressed). Otherwise, we should be able to get this in during the Essex-4 > > cycle, so it will still make the main Essex release. Please do me a favor > > and > > update the blueprint indicating whether you are planning on working on this > > for > > Essex-3. > > I delayed it to Essex-4 as the patch needs clean up and improvement. > So I think it would be difficult to make it at Essex-3. After consideration a bit, let me try to make it for Essex-3. -- yamahata -- Mailing list: https://launchpad.net/~netstack Post to : netstack@lists.launchpad.net Unsubscribe : https://launchpad.net/~netstack More help : https://help.launchpad.net/ListHelp
Re: [Netstack] Ryu support in Quantum
I requested the review at https://review.openstack.org/3055 If it's too late for Esses-3, please let me know. thanks in advance On Wed, Jan 11, 2012 at 04:55:14PM +0900, Isaku Yamahata wrote: > On Wed, Jan 11, 2012 at 11:15:03AM +0900, Isaku Yamahata wrote: > > > Also, thank you for registering a blueprint. To get the code merged into > > > Quantum, you will need to propose a diff for review following the standard > > > OpenStack development process (see: > > > http://wiki.openstack.org/GerritWorkflow). > > > > > > > > > Given that this looks like a pretty big patch, you should do this very > > > soon if > > > you would like this to be part of the Essex-3 release (code freeze date > > > is two > > > weeks away, but big patches from someone new to the project should be > > > proposed > > > well in advance of the code freeze to make sure all review comments can be > > > addressed). Otherwise, we should be able to get this in during the > > > Essex-4 > > > cycle, so it will still make the main Essex release. Please do me a > > > favor and > > > update the blueprint indicating whether you are planning on working on > > > this for > > > Essex-3. > > > > I delayed it to Essex-4 as the patch needs clean up and improvement. > > So I think it would be difficult to make it at Essex-3. > > After consideration a bit, let me try to make it for Essex-3. > -- > yamahata > > -- > Mailing list: https://launchpad.net/~netstack > Post to : netstack@lists.launchpad.net > Unsubscribe : https://launchpad.net/~netstack > More help : https://help.launchpad.net/ListHelp > -- yamahata -- Mailing list: https://launchpad.net/~netstack Post to : netstack@lists.launchpad.net Unsubscribe : https://launchpad.net/~netstack More help : https://help.launchpad.net/ListHelp
Re: [Netstack] Ryu support in Quantum
Thank you for review. Okay, the approach (distinct plugins + OVS-related library) sounds quite reasonable. So let's delay it to E-4 (or F). And I'll give the refactoring a try. BTW, I need a small twist to nova/network. Is it acceptable for you? I think it's harmless. https://review.openstack.org/#change,3175 thanks, On Thu, Jan 19, 2012 at 01:21:33AM -0800, Dan Wendlandt wrote: > Thanks Isaku. > > We chatted about this briefly at the netstack meeting on Tuesday. The > feeling was that the Ryu controller should probably be its own Quantum > plugin, in its own directory in the Quantum source. Even though both > plugins use open vswitch, their mode of operation actually seems quite > different (OVS plugin configures OVS locally without a controller, > while the Ryu plugin uses a OpenFlow controller). As the code bases > for both plugins grow, it is like that the set of supported features, > and the corresponding source code, configuration, documentation, etc. > will continue to diverge, leading to confusion for developers and > users if we do not split them out. > > That said, there definitely is some overlap in functionality. In > general, the goal for Quantum plugins is that code that is useful to > many plugins can be pulled into shared libraries, so that multiple > plugins can use it. I see two clear areas for doing so in this case: > > - taking some of the generic logic for getting/fetching nets + ports > from the SQLAlchemy datastore that is in the OVS quantum plugin and > putting it in a more generic QuantumPluginSqlAlchemy class, so it can > be leveraged by multiple plugins. Plugins that want to use the > SQLAlchemy datastore could just sub-class this base class. I would > imagine that the base class would create 'listener' methods (e.g., > on_network_create(network)) that a sub-class could implement if they > had special customization behavior to do whenever an particular event > happened (this is fairly similar to what your patch already did so > that the VLANMap logic was only invoked if using the OVS plugin, not > the Ryu plugin). > > - creating a shared library for some of the common OVS related agent > functionality (including manipulating the OVS integration bridge). > Creating a library will make it a bit more cumbersome to use the > agent, as there will be multiple agent files to copy over the > hypervisor, but we really need to get the agent packaged anyway, at > which point that concern should go away. > > Doing this kind of a refactoring is almost certainly too much to try > to squeeze into E-3, but it should certainly be possible to do in E-4. > Thanks, > > Dan > > > > On Sat, Jan 14, 2012 at 7:42 PM, Isaku Yamahata > wrote: > > I requested the review at > > https://review.openstack.org/3055 > > > > If it's too late for Esses-3, please let me know. > > > > thanks in advance > > > > On Wed, Jan 11, 2012 at 04:55:14PM +0900, Isaku Yamahata wrote: > >> On Wed, Jan 11, 2012 at 11:15:03AM +0900, Isaku Yamahata wrote: > >> > > Also, thank you for registering a blueprint. ?To get the code merged > >> > > into > >> > > Quantum, you will need to propose a diff for review following the > >> > > standard > >> > > OpenStack development process (see: > >> > > http://wiki.openstack.org/GerritWorkflow). > >> > > > >> > > > >> > > Given that this looks like a pretty big patch, you should do this very > >> > > soon if > >> > > you would like this to be part of the Essex-3 release (code freeze > >> > > date is two > >> > > weeks away, but big patches ?from someone new to the project should be > >> > > proposed > >> > > well in advance of the code freeze to make sure all review comments > >> > > can be > >> > > addressed). ?Otherwise, we should be able to get this in during the > >> > > Essex-4 > >> > > cycle, so it will still make the main Essex release. ?Please do me a > >> > > favor and > >> > > update the blueprint indicating whether you are planning on working on > >> > > this for > >> > > Essex-3. > >> > > >> > I delayed it to Essex-4 as the patch needs clean up and improvement. > >> > So I think it would be difficult to make it at Essex-3. > >> > >> After consideration a bit, let me try to make it for Essex-3. > >> -- > >> yamahata > >> > >> -- > >> Mailing list: https://launchpad.net/~netstack > >> Post to ? ? : netstack@lists.launchpad.net > >> Unsubscribe : https://launchpad.net/~netstack > >> More help ? : https://help.launchpad.net/ListHelp > >> > > > > -- > > yamahata > > > > -- > ~~~ > Dan Wendlandt > Nicira Networks:?www.nicira.com > twitter: danwendlandt > ~~~ > -- yamahata -- Mailing list: https://launchpad.net/~netstack Post to : netstack@lists.launchpad.net Unsubscribe : https://launchpad.net/~netstack More help : https://help.launchpad.net/ListHelp
[Netstack] quantum agent duplication
Hi. When I requested Ryu plugin merge, https://review.openstack.org/#change,3618 I noticed that others also has tries to introduce a new plugin, Linux bridge plugin. https://review.openstack.org/#change,3278 After those two plugins are merged, we'll have very similar three quantum agents. I think it's ok in short term, but how should we do in long term? Refactor those and introduce something like agent-common package and each agent packages? Or do nothing because the original intention seems that agent program should be a small independent program and it should be easy to install it. thanks, -- yamahata -- Mailing list: https://launchpad.net/~netstack Post to : netstack@lists.launchpad.net Unsubscribe : https://launchpad.net/~netstack More help : https://help.launchpad.net/ListHelp
Re: [Netstack] requirements for quantum plugins
On Fri, Jun 29, 2012 at 07:50:30AM +0100, Dan Wendlandt wrote: > Hi folks, > > Ryota from NEC sent an email to the list earlier tonight about pushing their > NEC Quantum plugin (currently hosted outside of the main Quantum repo), into > the main Quantum repo. As some of you will recall, at the Folsom summit we > talked a bit about whether plugins should be in core and if so, what the > requirements would be around allowing a plugin to be in the main repo. > > My personal feeling is that having plugins be part of a single centralized > community repository is a good thing for a couple of reasons: > 1) it simplifies and increases the sharing of code and ideas across different > plugins. > 2) it promotes a more cohesive community around quantum, encouraging people to > contribute not only to their plugin, but to community projects as well. > 3) it potentially makes it easier for someone to understand if a code change > (e.g., at the db plugin base layer) breaks any particular plugin. > > However, for this approach to work, I think we need to make sure that at least > one core quantum developer is committed to maintaining the plugin. Why a core > member? Because being core represents a significant commitment to > understanding the does and don'ts of Quantum, which that maintainer can help > enforce with respect to the plugin code. A core developer also presents a > commit to the community as a whole, which means other core developers will be > motivated to return the favor and reivew/fix issues within the plugin. > > Obviously, we don't want these requirements to be so high that they discourage > people from building and pushing plugin code to the main repo, because as I > mentioned above, I think there are a lot of advantages to having plugins in a > shared location. The core dev might be the primary developer of the plugin > itself, or it might be an existing core developer who is simply motivated to > work with the existing developers to help make sure the plugin stays in good > shape and questions on the ML or launchpad get answered in a reasonable > fashion. > > At this point, I would think that all plugins in the repo meet these criteria, > with the exception of the Ryu plugin, as we haven't really had much contact > with those authors since the initial contribution. Sorry for our low activity. I'm watching the mailing list, and please CC to me if the response is necessary. Let me explain our situation. The team is wondering how to move on to Quantum v2 API and scalable agent. thanks, > > What do others think about this topic? What's the right trade-off? > > Dan > > -- > ~~~ > Dan Wendlandt > Nicira, Inc: www.nicira.com > twitter: danwendlandt > ~~~ > > -- > Mailing list: https://launchpad.net/~netstack > Post to : netstack@lists.launchpad.net > Unsubscribe : https://launchpad.net/~netstack > More help : https://help.launchpad.net/ListHelp -- yamahata -- Mailing list: https://launchpad.net/~netstack Post to : netstack@lists.launchpad.net Unsubscribe : https://launchpad.net/~netstack More help : https://help.launchpad.net/ListHelp
Re: [Netstack] Quantum versions
On Sun, Jul 01, 2012 at 02:13:31PM +0300, Gary Kotton wrote: > Hi, > Can we please make a point to discuss this at tomorrow's meeting. I am > in favor of Dan's proposal. I think that we just need to come to a > consensus. There are a lot of comments regarding V1 and V2 on the > following patches: > - https://review.openstack.org/#/c/9160/ > - https://review.openstack.org/#/c/9101/ > I understand that v2 support for UCS will be done in F-3. What about the > RYU plugin? Ryu v2 support is under testing right now. After testing, we'll be able to request the review. thanks, -- yamahata -- Mailing list: https://launchpad.net/~netstack Post to : netstack@lists.launchpad.net Unsubscribe : https://launchpad.net/~netstack More help : https://help.launchpad.net/ListHelp
Re: [Netstack] Quantum versions
I registered https://blueprints.launchpad.net/quantum/+spec/update-ryu-plugin-for-v2 thanks, On Thu, Jul 05, 2012 at 06:01:01PM +0100, Dan Wendlandt wrote: > Hi Yamahata, > > Can you please create a BP for this work here? https://launchpad.net/quantum/ > +milestone/folsom-3 > > Thanks, > > Dan > > > On Thu, Jul 5, 2012 at 5:17 PM, Isaku Yamahata wrote: > > On Sun, Jul 01, 2012 at 02:13:31PM +0300, Gary Kotton wrote: > > Hi, > > Can we please make a point to discuss this at tomorrow's meeting. I am > > in favor of Dan's proposal. I think that we just need to come to a > > consensus. There are a lot of comments regarding V1 and V2 on the > > following patches: > > - https://review.openstack.org/#/c/9160/ > > - https://review.openstack.org/#/c/9101/ > > I understand that v2 support for UCS will be done in F-3. What about the > > RYU plugin? > > Ryu v2 support is under testing right now. After testing, we'll be able to > request the review. > > thanks, > -- > yamahata > > -- > Mailing list: https://launchpad.net/~netstack > Post to : netstack@lists.launchpad.net > Unsubscribe : https://launchpad.net/~netstack > More help : https://help.launchpad.net/ListHelp > > > > > -- > ~~~ > Dan Wendlandt > Nicira, Inc: www.nicira.com > twitter: danwendlandt > ~~~ > -- yamahata -- Mailing list: https://launchpad.net/~netstack Post to : netstack@lists.launchpad.net Unsubscribe : https://launchpad.net/~netstack More help : https://help.launchpad.net/ListHelp
Re: [Netstack] Quantum versions
Our internal review/test of the first patch is done now. Kaneko of our team will mainly take care of it, so I changed its assignee to him. Off course, I'm following him. thanks, On Fri, Jul 06, 2012 at 10:19:10AM +0900, Isaku Yamahata wrote: > I registered > https://blueprints.launchpad.net/quantum/+spec/update-ryu-plugin-for-v2 > > thanks, > > On Thu, Jul 05, 2012 at 06:01:01PM +0100, Dan Wendlandt wrote: > > Hi Yamahata, > > > > Can you please create a BP for this work here? > > https://launchpad.net/quantum/ > > +milestone/folsom-3 > > > > Thanks, > > > > Dan > > > > > > On Thu, Jul 5, 2012 at 5:17 PM, Isaku Yamahata > > wrote: > > > > On Sun, Jul 01, 2012 at 02:13:31PM +0300, Gary Kotton wrote: > > > Hi, > > > Can we please make a point to discuss this at tomorrow's meeting. I am > > > in favor of Dan's proposal. I think that we just need to come to a > > > consensus. There are a lot of comments regarding V1 and V2 on the > > > following patches: > > > - https://review.openstack.org/#/c/9160/ > > > - https://review.openstack.org/#/c/9101/ > > > I understand that v2 support for UCS will be done in F-3. What about > > the > > > RYU plugin? > > > > Ryu v2 support is under testing right now. After testing, we'll be able > > to > > request the review. > > > > thanks, > > -- > > yamahata > > > > -- > > Mailing list: https://launchpad.net/~netstack > > Post to : netstack@lists.launchpad.net > > Unsubscribe : https://launchpad.net/~netstack > > More help : https://help.launchpad.net/ListHelp > > > > > > > > > > -- > > ~~~ > > Dan Wendlandt > > Nicira, Inc: www.nicira.com > > twitter: danwendlandt > > ~~~ > > > > -- > yamahata > > -- > Mailing list: https://launchpad.net/~netstack > Post to : netstack@lists.launchpad.net > Unsubscribe : https://launchpad.net/~netstack > More help : https://help.launchpad.net/ListHelp > -- yamahata -- Mailing list: https://launchpad.net/~netstack Post to : netstack@lists.launchpad.net Unsubscribe : https://launchpad.net/~netstack More help : https://help.launchpad.net/ListHelp
Re: [Netstack] [openstack-dev] [Quantum]NEC OpenFlow Plugin: Agent and Packet Filter
On Sun, Aug 12, 2012 at 03:31:10PM -0700, Dan Wendlandt wrote: > [Agent or VIFDriver] > This plugin has an agent that corrects only port information. Another > solution is plugin-specific VIFDriver/InterfaceDriver that > plugs interface, gets port information and sends it to Quantum Server. > The reason why I modified agent: there are some discussions about plugging > a network interface around F summit. 1. Plugin specific > codes should be separate from nova. 2. VIFDriver should be focused on > only > plugging (work something required to plug: e.g.. > VIFDriver for Cisco plugin finds which device to plug). > But, Ryu plugin has plugin-specific VIFDriver(and InterfaceDriver) that > plugs VIF and corrects port information. It is similar to > NEC Plugin's VIFDriver for Essex. Is this acceptable? > Or, plugin developer can choice it with considering trade-off between code > separation and behavior simplification. > > > The Ryu vif-driver is in the Quantum repo, which in general is bad and has led > to breakage as things change in Nova, and the vif-driver that is not in nova > gets out of date. Thus, I'd rather arrive at a model where all vif-drivers > are > in Nova. Right now I'm addressing elimination of Ryu specific vif driver by replacing OVS's with iface-id in ovsdb. > What we want to avoid is complex and frequently changing logic in the Nova > vif-plugging. What would be nice to arrive at is if we could get a common > model used by many plugins to report information from the vif-plugging back to > Quantum. With that, Quantum would have a way of providing data to Nova (i.e., > the data returned by the port create request) and Nova would have the ability > to report any data resulting from the plug back to Quantum. Between the two, > I > think we should have most bases covered. This founds like a good topic for > the > Grizzly summit. I'll add it to my list of topics to suggest :) Yes, this will be very useful. -- yamahata -- Mailing list: https://launchpad.net/~netstack Post to : netstack@lists.launchpad.net Unsubscribe : https://launchpad.net/~netstack More help : https://help.launchpad.net/ListHelp
