Open Stack

Hi all,


I pushed NEC OpenFlow Plugin to gerrit.
https://review.openstack.org/#/c/10664/
I got some comments, and I'm wondering next action. Comments are welcomed.

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

[Packet Filter extension]
This patch includes a new extension "Packet Filter". It is intended to expose functionality of packet filtering provided by Trema
(OpenFlow Controller). I put this extension for the following reasons:  1. This plugin for quantum v1.x (not in quantum tree)
supports packet filtering.  2. This will help baremetal people who cannot use netfilter(iptables) on nova-compute nodes.
This could be an element of Security Groups. I feel we need discussion including Security Group API in two points;
1. What is the position of this extension? I think we need some "Internal" Security Group API for adopting a FW Appliance instead of
netfilter(iptables), and this extension could be a starting-point of the discussion.
2. Is it acceptable that put this extension until Security Group API is ready? (This extension should be internal methods after
Security Group API is ready.)
Should I keep it in the patch or separate it and write new bp?


Thanks,

Ryota MIBU