00:04:55 <SridarK> #startmeeting Networking FWaaS
00:04:56 <openstack> 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 <openstack> Useful Commands: #action #agreed #help #info #idea #link #topic #startvote.
00:04:59 <openstack> The meeting name has been set to 'networking_fwaas'
00:05:04 <SridarK> #chair xgerman
00:05:05 <openstack> Current chairs: SridarK xgerman
00:05:32 <SridarK> we can run thru things quickly
00:05:38 <xgerman> yep
00:05:38 <SridarK> #topic FWaaSv2
00:06:02 <xgerman> I added some versioned objects but I am mostly consumed with LBaaS/internal stuff
00:06:37 <SridarK> on my end, i got stuck with some issues on the db integration -  i think i may have found one issue
00:06:56 <SridarK> i am hoping this will lead to some light
00:06:56 <xgerman> yeah, I am not sure if we have all the bak-refs in that model
00:07:02 <SridarK> xgerman: yes i saw that
00:07:19 <SridarK> on the versioned obj
00:07:41 <xgerman> yeah, I haven’t seen how they are unit tested so not sure...
00:07:47 <SridarK> yes
00:07:58 <SridarK> i am mostly testing with devstack
00:08:32 <xgerman> k, mickeys any progress?
00:08:38 <SridarK> ok we will continue with this
00:09:07 <mickeys> 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 <xgerman> cool!
00:09:46 <SridarK> mickeys: that is great
00:09:57 <mickeys> 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 <mickeys> If the latter, a really small singleton.
00:10:49 <mickeys> We still need a bigger singleton for the conntrack zone stuff since that needs to be shared between SG and FWaaS
00:11:12 <mickeys> We need to code some of this up and test to make sure it works.
00:11:18 <xgerman> ok, I think singletons are the right approach
00:11:21 <SridarK> when the first instance of the feature is configured we register ?
00:11:49 <mickeys> 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 <xgerman> yeah, we can register once we load the extension
00:12:13 <mickeys> Each feature would just add a line
00:12:53 <SridarK> ok thats fair to do it at ext load
00:13:22 <xgerman> 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 <mickeys> 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 <mickeys> Anyway, will think about it and propose something.
00:14:53 <xgerman> sounds good
00:15:10 <jwarendt> look forward to the proposal
00:15:21 <SridarK> ok also we shd think of some testcases to make sure we flush out any interop issues with SG and FWaaS
00:16:25 <xgerman> yep, test will be important
00:16:36 <mickeys> 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 <mickeys> In the existing code
00:16:51 <xgerman> I would assume SG is in the integration gate :-)
00:17:13 <mickeys> We noticed that there were other features running iptables, but have not tried any of them. One was metering.
00:17:38 <xgerman> mmh, guess we need some proper testing
00:17:56 <xgerman> I thought metering worked only in non-DVR
00:18:14 <xgerman> so already has issues
00:18:44 <mickeys> 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 <xgerman> mmh,… we can ask on the ML?
00:19:28 <mickeys> If FWaaS hits first, the address scope rules will not be applied.
00:19:55 <xgerman> I think sc68cal is at the QA midcycle
00:20:15 <xgerman> and the Neutron people are at their mid cycle… so ML might be best
00:20:28 <mickeys> 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 <SridarK> it seems pandora's box is open :-)
00:21:34 <mickeys> The whole area of multiple IptablesManager instances is a bit scary
00:21:50 <xgerman> well, we can always ask for a design session to straighten that out
00:22:03 <xgerman> dougwig?
00:22:22 <xgerman> or better armax?
00:22:39 <xgerman> but it’s dinner time in Rochester… so...
00:22:45 <SridarK> yes it seems will be good to flush this out with the set of folks touching iptables
00:23:27 <xgerman> yeah, that would be good
00:23:35 <mickeys> 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 <mickeys> Already merged.
00:24:12 <xgerman> nice
00:24:24 <SridarK> mickeys: can u pls pass the link
00:24:41 <mickeys> #link https://bugs.launchpad.net/neutron/+bug/1549513
00:24:41 <openstack> Launchpad bug 1549513 in neutron "Feature specific code should be moved out of iptables_manager" [Undecided,New]
00:24:46 <SridarK> Thanks
00:25:17 <mickeys> Not my bug merged, the code I am not thrilled about already merged
00:25:47 <xgerman> that happens
00:26:35 <mickeys> Probably no functional impact on us, just extra copy actions from connmark to mark. Assuming we do not use mark.
00:28:03 <xgerman> never assume
00:28:20 <xgerman> I am still a bit worried that this is a free4all
00:28:20 <mickeys> Well if they clean it up then it won't be an issue
00:28:29 <xgerman> +1
00:28:46 <SridarK> yes it is good u raised the promptly
00:28:53 <SridarK> *the bug
00:28:57 <xgerman> +1
00:29:30 <SridarK> Any other things to discuss on v2 ?
00:29:51 <mickeys> 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 <mickeys> Different chains, no issue
00:30:14 <xgerman> but we need to jump from one chain to the other
00:30:36 <mickeys> At some point some chain needs to be shared, and then jump to different chains
00:30:54 <xgerman> +1
00:30:58 <mickeys> Usually FORWARD, etc
00:34:22 <SridarK> ok lets move on
00:34:37 <xgerman> +1
00:34:43 <SridarK> #topic other reviews, patches
00:35:16 <SridarK> I wanted to bring up new vendor patches
00:35:25 <xgerman> nice
00:35:42 <xgerman> how’s the other baharath’s patch coming?
00:35:44 <SridarK> 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 <xgerman> yep
00:35:59 <SridarK> #link https://review.openstack.org/#/c/283882/
00:37:22 <SridarK> ok sounds good we can start reviews on that
00:37:29 <xgerman> yep
00:37:42 <SridarK> on the observer hierarchy
00:37:48 <SridarK> #link https://review.openstack.org/#/c/278863/
00:37:55 <SridarK> i think this needs more work
00:38:06 <SridarK> will comment on the patch
00:38:11 <xgerman> k
00:38:28 <madhu_ak> 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 <xgerman> +1
00:38:50 <SridarK> yes agreed
00:38:58 <xgerman> madhu_ak  thanks for fixing that job
00:39:24 <madhu_ak> oh yeah. We have the gate job running smoothly after fixing the db part in hooks
00:40:09 <madhu_ak> for those who wanted to check, one can leave a comment - 'check experimental' to get job results
00:41:07 <madhu_ak> also, I posted a patch on projct-config to remove redundant job, #link https://review.openstack.org/#/c/283869/
00:42:09 <SridarK> madhu_ak: thx
00:43:15 <xgerman> +1
00:43:19 <SridarK> other patches or reviews needing attention ?
00:43:37 <xgerman> there are some form jwarendt - but they seem to be moving nicely
00:44:02 <SridarK> yes jwarendt: thx for resurrecting the quotas patchset
00:44:02 <xgerman> jwarendt is also investigating how we can detangle FWaaS V1 from Neutron
00:44:08 <xgerman> +1
00:44:20 <jwarendt> np
00:44:41 <SridarK> nice thx
00:45:05 <SridarK> jwarendt: do u have a bug/rfe for that
00:47:06 <jwarendt> This is building on old bug 1500960.
00:47:06 <openstack> 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 <xgerman> we probably should change the assignment ;-)
00:47:41 <SridarK> aah ok got it
00:48:06 <SridarK> there is possibly some overlap on the observer hierarchy work as well
00:48:10 <xgerman> yep
00:48:15 <xgerman> I would assume so
00:48:33 <SridarK> ok great this would be good
00:48:48 <jwarendt> 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 <SridarK> jwarendt: pls feel free to ping me on any thing on the l3 agent - fwaas blasphemy
00:49:45 <SridarK> i worked on that stuff in Havana
00:50:16 <jwarendt> Will do.
00:51:21 <SridarK> ok cool if nothing else on this lets move to open discussion
00:51:26 <xgerman> yep
00:51:30 <SridarK> #topic Open Discussion
00:51:37 <xgerman> #link http://lists.openstack.org/pipermail/openstack-dev/2016-February/086007.html
00:51:47 <xgerman> Proposal: Separate design summits from OpenStack conferences
00:52:09 <xgerman> just as an FYI
00:52:47 <SridarK> in some sense this an opportunity to meet with actual folks who deploy - so i have mixed feelings on this
00:53:09 <xgerman> yep, it’s a double edged sword
00:53:28 <SridarK> but yes exactly there is definite value in a focussed design summit
00:53:32 <SridarK> hard call
00:53:53 <xgerman> and given companies’ budgets a cheaper location probably better
00:54:26 <SridarK> surely
00:54:36 <xgerman> anything else?
00:54:44 <SridarK> nothing else from me
00:55:23 <SridarK> ok folks then if no one has anything else to discuss - we can end
00:55:28 <xgerman> +1
00:55:38 <SridarK> have a great rest of the week everyone
00:55:40 <SridarK> thx
00:55:44 <jwarendt> Thank you
00:55:47 <xgerman> thx
00:55:51 <xgerman> o/
00:55:54 <hoangcx> Thank yyou
00:56:02 <bharathm> Thanks everyone
00:56:12 <SridarK> #endmeeting