00:04:55 #startmeeting Networking FWaaS 00:04:56 Meeting started Thu Feb 25 00:04:55 2016 UTC and is due to finish in 60 minutes. The chair is SridarK. Information about MeetBot at http://wiki.debian.org/MeetBot. 00:04:57 Useful Commands: #action #agreed #help #info #idea #link #topic #startvote. 00:04:59 The meeting name has been set to 'networking_fwaas' 00:05:04 #chair xgerman 00:05:05 Current chairs: SridarK xgerman 00:05:32 we can run thru things quickly 00:05:38 yep 00:05:38 #topic FWaaSv2 00:06:02 I added some versioned objects but I am mostly consumed with LBaaS/internal stuff 00:06:37 on my end, i got stuck with some issues on the db integration - i think i may have found one issue 00:06:56 i am hoping this will lead to some light 00:06:56 yeah, I am not sure if we have all the bak-refs in that model 00:07:02 xgerman: yes i saw that 00:07:19 on the versioned obj 00:07:41 yeah, I haven’t seen how they are unit tested so not sure... 00:07:47 yes 00:07:58 i am mostly testing with devstack 00:08:32 k, mickeys any progress? 00:08:38 ok we will continue with this 00:09:07 Not enough. We investigated the iptables chains a little more and think we know what we want to do to let both SG and FWaaS run at the same time. 00:09:21 cool! 00:09:46 mickeys: that is great 00:09:57 We will insert a common unwrapped chain. No singleton required for that, but there is still a question how to populate the jumps to SG and FWaaS specific chains. Either fixed logic based on what drivers are running, or a singleton where features can register jumps to their chains. 00:10:31 If the latter, a really small singleton. 00:10:49 We still need a bigger singleton for the conntrack zone stuff since that needs to be shared between SG and FWaaS 00:11:12 We need to code some of this up and test to make sure it works. 00:11:18 ok, I think singletons are the right approach 00:11:21 when the first instance of the feature is configured we register ? 00:11:49 If we have a small singelton for registration, then we just need it to hold the jumps to feature specific chains, from the common chain 00:12:08 yeah, we can register once we load the extension 00:12:13 Each feature would just add a line 00:12:53 ok thats fair to do it at ext load 00:13:22 yep, I think they are pushing neutron-lib hard so the less we need to be hardcoded in the innards the better 00:14:12 Actually, now that I think about it, there may be a way to do it without the singleton, but it does have a side effect. If each feature just adds the line itself, then I think the jumps will swap everytime a feature updates. Not sure if anyone cares about stats on the jump rule? 00:14:44 Anyway, will think about it and propose something. 00:14:53 sounds good 00:15:10 look forward to the proposal 00:15:21 ok also we shd think of some testcases to make sure we flush out any interop issues with SG and FWaaS 00:16:25 yep, test will be important 00:16:36 I think there is an issue with order of rules changing when multiple features have their own instances of IptablesManager. Right now it probably only affects the jump from the FORWARD to neutron-openvswi-FORWARD, if there is another feature that also jumps to wrap-name-FORWARD 00:16:40 In the existing code 00:16:51 I would assume SG is in the integration gate :-) 00:17:13 We noticed that there were other features running iptables, but have not tried any of them. One was metering. 00:17:38 mmh, guess we need some proper testing 00:17:56 I thought metering worked only in non-DVR 00:18:14 so already has issues 00:18:44 I found a case unrelated to FWaaSv2 that makes me nervous. For address scopes, they added some rules in filter FORWARD. Wondering if this will clash with existing FWaaS, since FWaaS has ACCEPT rules. Not sure how to determine whether FWaaS or address scope rules hit first. 00:19:28 mmh,… we can ask on the ML? 00:19:28 If FWaaS hits first, the address scope rules will not be applied. 00:19:55 I think sc68cal is at the QA midcycle 00:20:15 and the Neutron people are at their mid cycle… so ML might be best 00:20:28 One of us probably needs to bring up FWaaS with address scope (master within the last two weeks) and see what happens. 00:21:10 it seems pandora's box is open :-) 00:21:34 The whole area of multiple IptablesManager instances is a bit scary 00:21:50 well, we can always ask for a design session to straighten that out 00:22:03 dougwig? 00:22:22 or better armax? 00:22:39 but it’s dinner time in Rochester… so... 00:22:45 yes it seems will be good to flush this out with the set of folks touching iptables 00:23:27 yeah, that would be good 00:23:35 The address scopes feature added some feature specific code to __init__ in iptables_manager. I just opened a bug against that an hour or two ago. 00:23:58 Already merged. 00:24:12 nice 00:24:24 mickeys: can u pls pass the link 00:24:41 #link https://bugs.launchpad.net/neutron/+bug/1549513 00:24:41 Launchpad bug 1549513 in neutron "Feature specific code should be moved out of iptables_manager" [Undecided,New] 00:24:46 Thanks 00:25:17 Not my bug merged, the code I am not thrilled about already merged 00:25:47 that happens 00:26:35 Probably no functional impact on us, just extra copy actions from connmark to mark. Assuming we do not use mark. 00:28:03 never assume 00:28:20 I am still a bit worried that this is a free4all 00:28:20 Well if they clean it up then it won't be an issue 00:28:29 +1 00:28:46 yes it is good u raised the promptly 00:28:53 *the bug 00:28:57 +1 00:29:30 Any other things to discuss on v2 ? 00:29:51 I walked through the code carefully. As far as I can tell, the only bad effect of running multiple IptablesManager instances touching the same tables is when they are both populating rules into the same chain, then the order of the rules will probably swap depending on who updated last. 00:30:01 Different chains, no issue 00:30:14 but we need to jump from one chain to the other 00:30:36 At some point some chain needs to be shared, and then jump to different chains 00:30:54 +1 00:30:58 Usually FORWARD, etc 00:34:22 ok lets move on 00:34:37 +1 00:34:43 #topic other reviews, patches 00:35:16 I wanted to bring up new vendor patches 00:35:25 nice 00:35:42 how’s the other baharath’s patch coming? 00:35:44 do we have a stand on this ? It seems that we should be ok and they can migrate to v2 when it is available 00:35:52 yep 00:35:59 #link https://review.openstack.org/#/c/283882/ 00:37:22 ok sounds good we can start reviews on that 00:37:29 yep 00:37:42 on the observer hierarchy 00:37:48 #link https://review.openstack.org/#/c/278863/ 00:37:55 i think this needs more work 00:38:06 will comment on the patch 00:38:11 k 00:38:28 I think its time to move experimental job for tempest tests into non voting, so it can test for any patches coming in? 00:38:40 +1 00:38:50 yes agreed 00:38:58 madhu_ak thanks for fixing that job 00:39:24 oh yeah. We have the gate job running smoothly after fixing the db part in hooks 00:40:09 for those who wanted to check, one can leave a comment - 'check experimental' to get job results 00:41:07 also, I posted a patch on projct-config to remove redundant job, #link https://review.openstack.org/#/c/283869/ 00:42:09 madhu_ak: thx 00:43:15 +1 00:43:19 other patches or reviews needing attention ? 00:43:37 there are some form jwarendt - but they seem to be moving nicely 00:44:02 yes jwarendt: thx for resurrecting the quotas patchset 00:44:02 jwarendt is also investigating how we can detangle FWaaS V1 from Neutron 00:44:08 +1 00:44:20 np 00:44:41 nice thx 00:45:05 jwarendt: do u have a bug/rfe for that 00:47:06 This is building on old bug 1500960. 00:47:06 bug 1500960 in neutron "Decouple FwaaS from L3 Agent" [Low,Confirmed] https://launchpad.net/bugs/1500960 - Assigned to Sean M. Collins (scollins) 00:47:36 we probably should change the assignment ;-) 00:47:41 aah ok got it 00:48:06 there is possibly some overlap on the observer hierarchy work as well 00:48:10 yep 00:48:15 I would assume so 00:48:33 ok great this would be good 00:48:48 Yes. I can build neutron without fwaas tree now, and have turned around the dependency (l3 agent was subclassing from FWaaS) but am in testing phase. 00:49:24 jwarendt: pls feel free to ping me on any thing on the l3 agent - fwaas blasphemy 00:49:45 i worked on that stuff in Havana 00:50:16 Will do. 00:51:21 ok cool if nothing else on this lets move to open discussion 00:51:26 yep 00:51:30 #topic Open Discussion 00:51:37 #link http://lists.openstack.org/pipermail/openstack-dev/2016-February/086007.html 00:51:47 Proposal: Separate design summits from OpenStack conferences 00:52:09 just as an FYI 00:52:47 in some sense this an opportunity to meet with actual folks who deploy - so i have mixed feelings on this 00:53:09 yep, it’s a double edged sword 00:53:28 but yes exactly there is definite value in a focussed design summit 00:53:32 hard call 00:53:53 and given companies’ budgets a cheaper location probably better 00:54:26 surely 00:54:36 anything else? 00:54:44 nothing else from me 00:55:23 ok folks then if no one has anything else to discuss - we can end 00:55:28 +1 00:55:38 have a great rest of the week everyone 00:55:40 thx 00:55:44 Thank you 00:55:47 thx 00:55:51 o/ 00:55:54 Thank yyou 00:56:02 Thanks everyone 00:56:12 #endmeeting