Open Stack

Hi Kyle, Ian, Akihiro

Thank you for your comment!

1. Iptables apply timing
In order to avoid the timing in which security group is not applied,
we should apply iptables rule
before each-agent connect vif to bridge.
IMO, l2-agent is only place to do that.
I have already tested, iptables rule can applied before tap device is
created. So it could be before plug interface.

2.Interface of firewall.py
This is my proposal of firewall.py
firewall.py  https://github.com/nttmcl/quantum/commit/4987b0ade5e130a38a397c40a81a9ddcfee1bf7a

In this bp, I will implement Iptables implementation of firewall class.
OpenFlow based one could be future candidate. We may can use same
openflow based security group implementation on
different OpenFlow-based plugins ( I'm not sure though)

3.Target of this bp
As Akihiro says, the target of bp is LB and OVS only now. However I
wanna design more generic internal python api using firewall.py.

2012/11/7 Akihiro MOTOKI <motoki at da.jp.nec.com>:
> Hi Nachi, Kyle and Quantum folks,
>
>>>>>> Date: Wed, 7 Nov 2012 15:22:20 +0000
>>>>>> From: "Kyle Mestery (kmestery)" <kmestery at cisco.com>
>>>>>> Subject: Re: [openstack-dev] [Quantum] Need review for iptablessecuritygroup bp
>>
>> On Nov 6, 2012, at 5:49 PM, Nachi Ueno <nachi at nttmcl.com> wrote:
>> > Hi Quantum folks
>> >
>> > I need to be reviewd  iptables securitygroup bp.
>> > I updated the bp using Gary's template.
>> >
>> > https://blueprints.launchpad.net/quantum/+spec/quantum-security-groups-iptables
>> >
>> > Actually, I have started the coding, but I do want get the spec agreed
>> > before code review.
>> >
>> Hi Nachi:
>>
>> This looks pretty good. So effectively, the security group code will be run before direct port
>> operations are undertaken on the host itself, right?
>
> I think it is an important point. To define iptables rules for a specific
> quantum logical port, the tap device needs to be created and attached to a
> bridge. Quantum cannot know the exact timing where a tap device is attached
> to a bridge. As far as we use agent-based approach some timing lag cannot be
> avoid (if my understanding is correct).
>
>> I notice the blueprint only mentions LinuxBridge and OVS plugins. I assume
>> there is some anticipated work for the other plugins (Ryu, NEC, NVP, and
>> Cisco) once this work lands?
>
> security group extension has been merged, but no OSS implementations are
> available for now. Nachi's BP focuses to address it, so he only mentions OVS
> and LB only.
>
> Aaron already has security group implementaiton for NVP plugin.
> It is under review and I feel it is near merge.
> I am also implementing NEC plugin support using OpenFlow.
>
>> For instance, is iptables required for each
>> plugin? I imagine Ryu could simply implement security groups using
>> OpenFlow rules for example.
>
> iptables is not required for each plugin.
> IMO, Linux Bridge plugin uses iptables, but OVS plugin uses its own
> filtering mechanism. OVS and iptables cannot coexists at the now.
> It is the reason that Nachi says OVS with iptables requires HybridDriver.
>
> It is true ryu can implement sg using OpenFlow though I am not sure how ryu
> plugin supports sg. The same thing applies to other OpenFlow based plugin
> such as  NVP, NEC, floodlight et el.
>
> Thanks,
> Akihiro
>>
>> Thanks,
>> Kyle
>>
>> > Thanks
>> > Nachi
>> >
>> > _______________________________________________
>> > OpenStack-dev mailing list
>> > OpenStack-dev at lists.openstack.org
>> > http://lists.openstack.org/cgi-bin/mailman/listinfo/openstack-dev
>>
>>
>>
>> _______________________________________________
>> OpenStack-dev mailing list
>> OpenStack-dev at lists.openstack.org
>> http://lists.openstack.org/cgi-bin/mailman/listinfo/openstack-dev
>
> _______________________________________________
> OpenStack-dev mailing list
> OpenStack-dev at lists.openstack.org
> http://lists.openstack.org/cgi-bin/mailman/listinfo/openstack-dev