04:00:27 #startmeeting networking_fwaas 04:00:28 Meeting started Wed Jul 6 04:00:27 2016 UTC and is due to finish in 60 minutes. The chair is xgerman. Information about MeetBot at http://wiki.debian.org/MeetBot. 04:00:30 Useful Commands: #action #agreed #help #info #idea #link #topic #startvote. 04:00:32 The meeting name has been set to 'networking_fwaas' 04:00:40 that was weird had to finish another meeting 04:00:43 Hi, all 04:00:49 Hi! 04:00:50 hi xgerman 04:00:53 Hi o/ 04:00:54 hi all 04:00:58 o/ 04:01:02 both Nate and Sridar are traveling so they asked me to run the meeting ;-) 04:01:17 #topic Announcements 04:02:08 Newton-2 is next week - #link http://releases.openstack.org/newton/schedule.html 04:02:23 time is flying!! 04:02:53 any other announcements? 04:03:54 #topic progress reports 04:05:32 I have seen the devstack plugin merge while I was gone — great job everybody!! 04:05:54 anything we should review? 04:06:11 xgerman: I have posted an update of the driver patch and description 04:06:30 would like your comments plz 04:06:53 https://docs.google.com/document/d/1yGsGwVNZuptPCzMMgBH4AHVkdoeWvQxsT5Wql7-jtHI/edit?pref=2&pli=1 04:07:21 that’s a great document. I will make sure to have a look 04:08:25 Me and Sarath will be concentrating on in v2 driver and test case this week, will push out something by next week 04:09:16 chandanc_, great! 04:09:23 +1 04:09:43 thanks :), will wait for comments 04:09:53 will sure have some ;-) 04:10:01 :) 04:12:20 I also have seen Magret making great progress on the L3 extension work 04:12:38 anything else? 04:12:48 * xgerman is feeling this will be a short meeting ;-) 04:13:26 if not 04:13:27 Can we get a status on the l2 agent side ? 04:13:37 just curious 04:13:53 I will have to read the code for the driver part 04:14:18 xgerman, chandanc_ L2-agent side, sorry for the slow progress. I was illness last Friday. 04:14:27 chandanc_# Yushiro's patch is out at https://review.openstack.org/#/c/323971/ 04:14:40 no worries, I have been out the last 7 days... 04:15:10 so, with your driver patch, the south bound progress will proceed :) 04:15:22 no problems, just want it for my referance 04:15:26 yushiro there was some confusion if the extension should go into neutron lib or neutron. I think that got settled towards putting it into neutron 04:15:52 the versioned object change is pending at my side :) 04:15:55 otherwise the extension is pretty similar to the L3 one — there are even cut&paste errors ;-) 04:16:05 padkrish great!! 04:16:41 xgerman, Yes. I'm just confusing about that. I hope the extension will keep in neutron. 04:17:19 the extensions frameworks will all move to neutron-lib but the timeline is unclear 04:17:42 xgerman, Ah, I understand. 04:17:44 basically development is in neutron and when it matures it should be promoted to neutron-lib 04:18:11 at the end (and as a criteria to stay in the stadium) FWaaS should only interface with lib 04:18:29 I see. 04:18:57 yeah, but with all the parts moving we decided to just tackle Neutron + FWaaS for now... 04:20:32 #topic Open Discussion 04:21:31 I think we had some discussion around the iptables/chains we should use — 04:22:08 Basically chandanc_ proposed: 04:22:14 https://www.irccloud.com/pastebin/7UVhpjqz/ 04:23:25 BTW: that whole chain thing is ripe for some extension mechanism as well but let’s not overdo it :-) 04:23:39 xgerman: yes, but after a little more study I think the common framework is already in place. I have some explanation in the google doc 04:23:59 ok, so we have a plan ;-) 04:24:02 We do not need to create a new chain 04:24:20 we sure have a plan :) 04:24:26 as per the new thoughts :) 04:24:48 Nice!! 04:25:31 I just remember we broke in LBaaS or FWaaS the metering plugin (which was basically counting bytes) 04:25:57 so there are other things which change the chains... 04:26:28 can I get some context of what happened ? 04:27:06 you mean the l3 metering part ? 04:27:31 yeah, I think that was the plugin. 04:27:33 xgerman the main top level chains such as neutron-openvswi-FORWARD/INPUT/OUTPUT do not change 04:27:55 each service such as SG, FWaaS inserts its related chains under them 04:28:22 correct me if I am wrong here 04:28:30 I will check the metering part just to be sure 04:28:56 as per the code iptables_manager creates these top level chains 04:29:11 and are used by SG driver 04:30:26 yeah, things work usually quite well but once we have the test we need to check on exotic combination like no SG and only FW and so on 04:30:47 have the code test exotic combinations... 04:30:47 Yes.. there is also one area which is not clear 04:31:25 SG worked if a port was associated with multiple SGS because it did not have a deny rule 04:31:36 for FWaaS this introduces rule ordering problem 04:31:37 xgerman: +1 04:31:46 and the need for having some priority associated 04:33:26 I remember we have priorities but deny would always win and we deny by default(?) 04:34:28 xgerman, Correct. In FWaaS v2 SPEC, it is described "deny wins" when SG and FW are mixtured. 04:34:45 Yes.. deny wins across stratum 04:34:59 but in the same stratum allow wins 04:35:26 mmh, SG would be a different stratum so... 04:36:03 am thinking of the scenario where a port is associated with two firewall groups and one allows while other denies 04:36:06 the confusion was, if there are more then one firewall group associated with the port, and one of them allows another denies 04:36:16 :) carry on 04:36:21 :) 04:36:46 got it so per our logic it would allow but it might feel funny for the user... 04:37:14 actually we dont know .. until we have some rule ordering :( 04:37:17 actually , it will depend on the order the iptable rules are applied on the port 04:37:33 :( 04:37:41 :) 04:38:25 I was thinking that we should have a field called priority in the FW group 04:38:31 which can help us in the ordering 04:38:48 I thnk the spec was not very clear on this, or we are missing something 04:39:05 yeah, groups are not ordered 04:39:35 chandanc_, SarathMekala Are you talking about following situation? fwg1( 1.deny SSH), fwg2(1. allow HTTP, 2.deny SSH) port is associated fwg1 and fwg2. 04:40:10 In this situation, what happened SSH communication? allowed or dropped ? 04:40:11 yes similar, with fgw2 allow SSH 04:40:27 yes 04:40:34 basically contradicting FW policies on a port 04:41:11 Then, can priority even help? since priority can also be set to same? :) 04:41:24 good one :) 04:41:59 :) yeah.. but that it will be users discretion... 04:42:12 the system can become deterministic with priority 04:42:26 should probably send a mail, with the explanation of the situation and give everyone some time to think through ? 04:42:43 its captured in the doc 04:43:02 SarathMekala# Agree 04:43:05 so please provide any feedback in the comments 04:43:14 +1 04:43:20 my bad, will await comments 04:43:46 chandanc_ no worries I was also hoping we could resolve tonight 04:43:55 but this is more complex :-( 04:44:24 anyhow, anything else? 04:44:28 ya, the situation is better for SG, as they only deal with allow rules 04:45:09 +1 04:46:58 I will close then 04:47:07 #endmeeting