Hi Ryota, <br><br><div class="gmail_quote">On Thu, Aug 9, 2012 at 7:18 AM, Ryota MIBU <span dir="ltr"><<a href="mailto:r-mibu@cq.jp.nec.com" target="_blank">r-mibu@cq.jp.nec.com</a>></span> wrote:<br><blockquote class="gmail_quote" style="margin:0 0 0 .8ex;border-left:1px #ccc solid;padding-left:1ex">
Hi all,<br>
<br>
<br>
I pushed NEC OpenFlow Plugin to gerrit.<br>
<a href="https://review.openstack.org/#/c/10664/" target="_blank">https://review.openstack.org/#/c/10664/</a><br>
I got some comments, and I'm wondering next action. Comments are welcomed.<br></blockquote><div><br></div><div>Sorry, Quantum reviewers have been really swamped. Given that you proposed this early in F-3, and that NEC has been doing other great work in the OpenStack community (particularly, working on Quantum support in Horizon), I'm committed to making sure this gets in for Folsom. </div>
<div> </div><blockquote class="gmail_quote" style="margin:0 0 0 .8ex;border-left:1px #ccc solid;padding-left:1ex">
<br>
[Agent or VIFDriver]<br>
This plugin has an agent that corrects only port information. Another solution is plugin-specific VIFDriver/InterfaceDriver that<br>
plugs interface, gets port information and sends it to Quantum Server.<br>
The reason why I modified agent: there are some discussions about plugging a network interface around F summit. 1. Plugin specific<br>
codes should be separate from nova. 2. VIFDriver should be focused on only plugging (work something required to plug: e.g..<br>
VIFDriver for Cisco plugin finds which device to plug).<br>
But, Ryu plugin has plugin-specific VIFDriver(and InterfaceDriver) that plugs VIF and corrects port information. It is similar to<br>
NEC Plugin's VIFDriver for Essex. Is this acceptable?<br>
Or, plugin developer can choice it with considering trade-off between code separation and behavior simplification.<br></blockquote><div><br></div><div>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. </div>
<div><br></div><div>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 :) </div>
<div> </div><blockquote class="gmail_quote" style="margin:0 0 0 .8ex;border-left:1px #ccc solid;padding-left:1ex">
<br>
[Packet Filter extension]<br>
This patch includes a new extension "Packet Filter". It is intended to expose functionality of packet filtering provided by Trema<br>
(OpenFlow Controller). I put this extension for the following reasons: 1. This plugin for quantum v1.x (not in quantum tree)<br>
supports packet filtering. 2. This will help baremetal people who cannot use netfilter(iptables) on nova-compute nodes.<br>
This could be an element of Security Groups. I feel we need discussion including Security Group API in two points;<br>
1. What is the position of this extension? I think we need some "Internal" Security Group API for adopting a FW Appliance instead of<br>
netfilter(iptables), and this extension could be a starting-point of the discussion.<br>
2. Is it acceptable that put this extension until Security Group API is ready? (This extension should be internal methods after<br>
Security Group API is ready.)<br>
Should I keep it in the patch or separate it and write new bp?<br></blockquote><div><br></div><div>Ideally any large extension would be merged in as a separate patch from the main extension to keep the overall review manageable, but its probably too late for that. In general, plugins are free to expose whatever extensions they want, even if they are specific to the plugin, so I see no problem with that. In general I think there are two modes of filtering/firewalling: port-level firewalling (security groups are an example of this) and "middlebox"-firewalling (where the entity doing the filtering is actually a separate appliance). We'll have support for security groups very soon, but larger discussions around firewalling (particularly the appliance model) will probably have to wait until Grizzly summit.</div>
<div><br></div><div>Dan</div><div><br></div><div> </div><blockquote class="gmail_quote" style="margin:0 0 0 .8ex;border-left:1px #ccc solid;padding-left:1ex">
<br>
<br>
Thanks,<br>
<br>
Ryota MIBU<br>
<br>
<br>
<br>
_______________________________________________<br>
OpenStack-dev mailing list<br>
<a href="mailto:OpenStack-dev@lists.openstack.org">OpenStack-dev@lists.openstack.org</a><br>
<a href="http://lists.openstack.org/cgi-bin/mailman/listinfo/openstack-dev" target="_blank">http://lists.openstack.org/cgi-bin/mailman/listinfo/openstack-dev</a><br>
</blockquote></div><br><br clear="all"><div><br></div>-- <br>~~~~~~~~~~~~~~~~~~~~~~~~~~~<br>Dan Wendlandt <div>Nicira, Inc: <a href="http://www.nicira.com" target="_blank">www.nicira.com</a><br><div>twitter: danwendlandt<br>
~~~~~~~~~~~~~~~~~~~~~~~~~~~<br></div></div><br>