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