14:01:58 <yushiro> #startmeeting fwaas
14:01:59 <openstack> Meeting started Thu Jan 25 14:01:58 2018 UTC and is due to finish in 60 minutes.  The chair is yushiro. Information about MeetBot at http://wiki.debian.org/MeetBot.
14:02:00 <openstack> Useful Commands: #action #agreed #help #info #idea #link #topic #startvote.
14:02:03 <openstack> The meeting name has been set to 'fwaas'
14:02:15 <SridarK> yushiro: i think ur turn to run the mtg today ?
14:02:20 <yushiro> #chair SridarK yushiro  xgerman_
14:02:21 <openstack> Current chairs: SridarK xgerman_ yushiro
14:02:31 <yushiro> SridarK, Hi. I think today is xgerman_  :)
14:02:39 <chandanc> Hello all
14:02:41 <SridarK> ah ok
14:02:44 <yushiro> chandanc, Hi
14:02:54 <chandanc> hello yushiro
14:03:21 <yushiro> SridarK, However, if he is difficult to handle today, I will.
14:03:52 <yushiro> Is xgerman_ online?
14:04:17 <SridarK> sure yushiro and i am ok to run it - if it is difficult for u today as well
14:04:36 <yushiro> Thanks SridarK :)
14:04:40 <SridarK> I see xgerman_ online
14:04:55 <SridarK> perhaps he had to step away
14:05:51 <yushiro> yes, OK, let's start today's meeting.
14:05:57 <SridarK> yes
14:06:16 <yushiro> #topic Queens
14:07:01 <yushiro> Today is Q-3(FF) deadline.
14:07:58 <yushiro> Thanks for your review
14:09:36 <yushiro> Fixed default fwg bug,   co-existing,  netlink for ipv6, auto-association for default fwg
14:09:36 <SridarK> +1
14:10:18 <annp> +1
14:11:00 <yushiro> Regarding co-existing patch( https://review.openstack.org/#/c/535237), we need reno  I think.
14:11:23 <annp> yes, I think so too
14:11:52 <chandanc> yushiro: do you mean for the migration ?
14:11:54 <yushiro> chandanc, annp Thanks for your discussion.  I'm sorry I couldn't join your discussion more..
14:12:07 <SridarK> i believe we managed to get all the patches in before the deadline
14:12:16 <SridarK> we should also discuss https://review.openstack.org/#/c/536234/
14:12:36 <annp> Let me confirm: Have we tested with co-existence in case of sg=iptables_hybrid and fwaas=OVS?
14:12:51 <yushiro> SridarK, +1
14:13:31 <yushiro> chandanc, not migration but 'why this fix is necessary or background'
14:13:57 <chandanc> yushiro: ok got it
14:14:00 <annp> yushiro, +1
14:14:23 <yushiro> #link https://review.openstack.org/#/c/536234/
14:14:53 <chandanc> for patch from annp
14:14:53 <SridarK> yushiro: have we covered coexistence in one of our earlier L2 support patches (in terms of reno)
14:15:53 <SridarK> if we describle that earlier and this if 535237 is just a bugfix - we may be ok - but chandanc can u pls double check that
14:15:54 <chandanc> can we ask the end user to move to OVS based SG ? this is my only concern
14:17:30 <SridarK> chandanc: also in regard to question from annp on testing coexistence with sg iptables and FWaaS L2
14:17:46 <SridarK> i think we are good on that correct ?
14:18:02 <chandanc> SridarK: annp yes i did try the iptable + OVS combination
14:18:17 <yushiro> SridarK, Just a moment, let me check our previous patch.
14:18:20 <chandanc> and the failed case was the one we discussed in length
14:18:36 <chandanc> default firewall group should solve the issue
14:18:48 <annp> chandanc, really?
14:18:48 <SridarK> The failed case is mainly to due to conn track
14:18:54 <chandanc> yes
14:19:30 <chandanc> I still have to investigate one thing that annp pointed
14:20:04 <annp> chandanc, actually, I  don't think default fwg can resolve the issue.
14:20:31 <annp> because there is one conntrack system on a compute node
14:20:36 <chandanc> annp: can you describe the case ?
14:20:58 <annp> Today I try to test with case:
14:21:21 <chandanc> sure, please update the thread
14:21:36 <annp> SG=iptables, FWaaS=OVS,
14:22:24 <annp> VM1 with default SG allow ping, VM1 is attached with FWGA(No firewall rule)
14:22:37 <annp> VM2 is attached with SG only,
14:22:50 <annp> Ping from VM2 to VM1
14:23:01 <annp> We can ping from VM2 to VM1
14:23:18 <annp> VM2 is attached to default SG allow ping.
14:23:20 <yushiro> SridarK, we said "if a port is associated with both firewall group and security group, then a packet must be allowed by both features.
14:23:20 <yushiro> "
14:23:49 <SridarK> yushiro: +1
14:23:53 <chandanc> yushiro: +1
14:24:07 <annp> I think the ct_state is change from new -> +est-repl,
14:24:23 <xgerman_> o/
14:24:46 <chandanc> annp: please confirm your findings
14:25:28 <chandanc> once you have the results,
14:25:44 <annp> So if vm2 is attached to default fwg with allow ping rules, I think VM2 can ping vm1.
14:25:49 <chandanc> i can test on my system, but i have to redo my devstack
14:26:06 <annp> So I think default fwg is not good solution.
14:26:23 <annp> chandanc, please confirm the my test.
14:26:29 <yushiro> However, I think previous reno says about SG for OVS...(Not explicitly mentioned)
14:26:38 <SridarK> annp: but VM1 is attached to a FWG without a permit for icmp ?
14:26:58 <annp> yes,
14:27:21 <annp> I expect VM2 can't ping VM1
14:27:28 <SridarK> annp: yes
14:27:42 <SridarK> so it almost seems like FWaaS is bypassed ?
14:28:21 <annp> SridarK, yes, Because conntrack state is changed.
14:28:34 <SridarK> due to SG
14:28:38 <SridarK> on iptables
14:29:05 <chandanc> SridarK: annp i did not see this happen on my system, even with icmp allowed in FWG ping was not going through
14:29:37 <annp> Have you test with my case?
14:29:41 <xgerman_> same OS?
14:29:54 <SridarK> chandanc: annp: So i think we need to confirm this
14:30:06 <chandanc> yes, i will confirm
14:30:27 <yushiro> VM1(defaulg SG allow:ICMP) (FWG A)  ----- (default SG allow:ICMP)VM2
14:31:13 <annp> yes, ping from VM2 to VM1 is ok?
14:31:47 <annp> I don't have my system at home. But I just tested in my office.
14:32:33 <yushiro> OK, I'll test it on Ubuntu.
14:33:04 <chandanc> annp: as per my tests VM2 to VM1 ping fails, let me confirm
14:33:23 <SridarK> So on this case, one observation was that without VM2 having a default FWG (even if we had permit for icmp) things will fail
14:33:40 <chandanc> yes, that is the test i did
14:33:44 <SridarK> chandanc: ^^^ this is what u had observed correct ?
14:33:52 <chandanc> SridarK: +1
14:34:28 <annp> chandanc, hmm, let wait yushiro confirm. I think we should test careful
14:34:38 <chandanc> annp +1
14:34:43 <yushiro> annp sorry, I confused.    expect: failed to send ICMP from VM2 --> VM1   actual: success  ?
14:35:12 <annp> yushiro, yes, I expect failed
14:35:25 <yushiro> OK, I see.  will try it.
14:35:33 <chandanc> annp: can you send your test case in the same mail thread with expected result
14:35:47 <annp> yes, I will to in tomorrow.
14:35:51 <yushiro> annp, chandanc  +1
14:36:02 <SridarK> ok lets confirm the difference in findings on this scenario
14:36:05 <chandanc> ok
14:36:13 <annp> However, I think my patch still necessary :)
14:36:17 <SridarK> and we can continue the email thread
14:36:32 <SridarK> annp: on ur patch lets discuss that
14:37:00 <SridarK> annp: so u will prevent this scenario all together ?
14:37:21 <annp> Sridark, I mean we should prevent linuxbridge port
14:37:56 <chandanc> annp: you mean hybrid plug right ?
14:38:02 <SridarK> annp: yes
14:38:30 <annp> chandanc, no, if hybrid plug work corrects in coexistence mode. we no need to prevent.
14:38:40 <chandanc> oh
14:38:41 <xgerman_> +1
14:38:49 <annp> however, we should prevent linuxbridge port
14:39:26 <chandanc> annp +1
14:39:29 <SridarK> annp: so if we are doing coexistence we need both sg and FWaaS to be using ovs
14:39:29 <chandanc> i agree
14:40:06 <SridarK> annp: and ur patch validates that
14:40:10 <chandanc> if port.binding.vif_type == pb_def.VIF_TYPE_OVS:
14:40:10 <chandanc> if not port.binding.vif_details[pb_def.OVS_HYBRID_PLUG]:
14:40:11 <chandanc> return True
14:40:18 <chandanc> i was confused by this
14:40:24 <annp> SridarK, I mean mechanism driver= ovs or linuxbrige
14:40:44 <yushiro> SridarK, +1  This is our target
14:40:52 <annp> chandanc, we can remove if f not port.binding.vif_details[pb_def.OVS_HYBRID_PLUG] if hybrid port test ok
14:41:47 <chandanc> annp: i am more confused now
14:41:54 <chandanc> SG=iptables, FWaaS=OVS case you mmentioned
14:42:06 <chandanc> is it iptables or iptables_hybrid
14:42:12 <annp> my patch intend to prevent all ports, which doesn't support by fwg
14:42:16 <yushiro> annp, In current validation, there is no relation for mechanism driver.  I think it relates firewall_driver for security_group.
14:42:49 <yushiro> firewall_driver for security_group are 'noop', 'iptables_hybrid' or 'openvswitch'.
14:43:04 <chandanc> yushiro: yes +1
14:43:13 <annp> yushiro, current source code in master branch?
14:43:24 <annp> or my patch?
14:43:35 <yushiro> annp,  I mean ur patch
14:43:42 <annp> No,
14:44:38 <annp> my patch intend to prevent all ports, which are not supported by FWG at API side.
14:45:04 <annp> Let me take an example:
14:45:15 <annp> There is 2 compute node:
14:45:41 <annp> compute A(ml2=LinuxBridge),
14:45:56 <annp> ComputeB(ml2=OVS)
14:45:59 <yushiro> annp, Yes, I know.  However, a point is different.  My point is a parameter 'vif_details' of the port  relates firewall_driver.
14:47:14 <annp> yushiro, We can remove vif_details line if all tested with SG=iptables_hybrid and FWaaS(OVS) passed in code coexistence.
14:47:15 <chandanc> annp: am i correct in saying that your patch will allow only OVS + OVS case
14:47:44 <annp> chandanc, yes.
14:47:50 <yushiro> chandanc, I think so.
14:47:51 <chandanc> ok, in that case
14:47:59 <chandanc> i have only one concern
14:48:20 <chandanc> can we ask the user to move SG to OVS
14:48:27 <annp> Because I need your confirm with hybrid port test.
14:48:45 <chandanc> SridarK: xgerman_ do you think operators will agree
14:49:06 <SridarK> i have one clarfication before
14:49:18 <chandanc> SridarK: sure
14:49:19 <xgerman_> hard to know — we need to chat with them at one of the summits
14:49:46 <chandanc> hmm
14:49:58 <SridarK> annp: so on Compute A - we are running SG on iptables and Compute B SG on ovs ?
14:50:09 <yushiro> chandanc, Yes, that is your concern.  I think it's  so difficult to modify existing system.  So, preparing a new compute node with OVS ... or
14:50:35 <yushiro> hmm
14:50:41 <annp> SridarK, compute B can running with sg=iptables_hybrid or ovs
14:50:43 <chandanc> yushiro: agree if there is a staged migration path
14:51:35 <annp> From my understanding, compute A will running SG=iptables
14:52:35 <annp> with ml2 driver = openvswitch, there is 2 solution for SG: SG based iptables, it called iptables_hybrid
14:52:44 <annp> and SG based OVS
14:52:57 <chandanc> yes
14:53:04 <SridarK> agreed
14:53:31 <yushiro> Sorry guys, there is 8 minutes left.  Could you please continue after this meeting?
14:53:43 <annp> So, My patch will prevent ports, which are landed at compute A
14:53:59 <SridarK> ok
14:54:04 <chandanc> annp
14:54:22 <chandanc> i dont agree to prevent iptables based ports
14:54:27 <SridarK> yes lets put the specifics down on the email thread as well
14:54:34 <yushiro> #topic Open Discussion
14:54:34 <chandanc> hybrid is the only issue
14:54:48 <SridarK> ok one quick update in parallel
14:55:00 <SridarK> regarding the service driver Patch from doude
14:55:21 <doude> hi
14:55:23 <yushiro> Yes.
14:55:26 <yushiro> Hi
14:55:43 <SridarK> doude: pls go ahead
14:56:06 <doude> ok
14:56:19 <doude> so given the deadline we decided to postpone it for R
14:56:51 <SridarK> we agreed that doude will use an out of tree implementation for now for internal requirements
14:57:09 <doude> and for our customers we will write our own FWaaS service plugin for queens which implements my proposed interfece driver
14:57:16 <SridarK> doude: and u will file a bp and we will get this in R-1
14:58:02 <xgerman_> +1
14:58:09 <SridarK> doude thx for ur understanding
14:58:10 <doude> about that bp, how should proceed?
14:58:18 <chandanc> +1
14:58:20 <doude> *I
14:58:45 <SridarK> doude pls file it and u can pretty much replicate the contents that u have in ur bug
14:59:00 <SridarK> doude: and we can discuss more offline
14:59:08 <doude> ok
14:59:16 <yushiro> Is it better to file RFE?
14:59:29 <yushiro> BP ? Sorry, I just confused.
14:59:43 <SridarK> ah yes maybe
14:59:50 <SridarK> yushiro: blueprint
14:59:52 <SridarK> sorry
15:00:19 <yushiro> NP. Ah, OK, BP not RFE
15:00:28 <SridarK> annp: can u pls continue ur description after the mtg or put it in the email thread
15:00:35 <doude> what's RFE?
15:00:52 <SridarK> either is ok, xgerman_ which do u think is better ?
15:01:13 <yushiro> doude, Request For Enhancement.  It's same as bug report but adding a tag named 'rfe'.
15:01:27 <xgerman_> I think RfE is less work and likely sufficient
15:01:31 <yushiro> SridarK, xgerman_ I have 1 quick .
15:01:40 <yushiro> oh, it's time !
15:01:49 <xgerman_> we can go over :-)
15:01:50 <SridarK> xgerman_: ok makes sense
15:01:58 <SridarK> oh yes we can :-)
15:02:02 <yushiro> let's close weekly meeting now but please continue 1 thing :)
15:02:08 <SridarK> ok
15:02:16 <annp> SridarK, I think we can continue discuss after meeting
15:02:18 <yushiro> Thanks.
15:02:21 <yushiro> #endmeeting