Open Stack

Hi Ryota,

On Thu, Aug 9, 2012 at 7:18 AM, Ryota MIBU <r-mibu at cq.jp.nec.com> wrote:

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

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.


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

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


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

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.

Dan



>
>
> Thanks,
>
> Ryota MIBU
>
>
>
> _______________________________________________
> OpenStack-dev mailing list
> OpenStack-dev at lists.openstack.org
> http://lists.openstack.org/cgi-bin/mailman/listinfo/openstack-dev
>



-- 
~~~~~~~~~~~~~~~~~~~~~~~~~~~
Dan Wendlandt
Nicira, Inc: www.nicira.com
twitter: danwendlandt
~~~~~~~~~~~~~~~~~~~~~~~~~~~
-------------- next part --------------
An HTML attachment was scrubbed...
URL: <http://lists.openstack.org/pipermail/openstack-dev/attachments/20120812/6ecc4acb/attachment.html>