18:01:13 #startmeeting networking_policy 18:01:13 Meeting started Thu Aug 24 18:01:13 2017 UTC and is due to finish in 60 minutes. The chair is SumitNaiksatam. Information about MeetBot at http://wiki.debian.org/MeetBot. 18:01:14 Useful Commands: #action #agreed #help #info #idea #link #topic #startvote. 18:01:16 The meeting name has been set to 'networking_policy' 18:01:42 ##info agenda https://wiki.openstack.org/wiki/Meetings/GroupBasedPolicy#Aug_17th.2C_24_2017 18:01:52 #topic Subnetpools in resource_mapping driver 18:01:58 #link https://review.openstack.org/469681 18:02:14 tbachman: annak, as before, thanks for working on this 18:02:18 tbachman: thanks for comments 18:02:18 tbachman: thanks for the review 18:02:22 annak: np! 18:02:25 SumitNaiksatam: np! 18:02:30 annak: nice work! 18:02:31 i took a quick look as well 18:02:40 tbachman: +2 18:02:42 thanks :) 18:02:54 the tbachman the issue that tbachman did not strike me 18:02:58 * tbachman likes annak’s improvements to the code 18:03:03 i need to look more closely 18:03:16 yes, indeed annak great work 18:03:18 * tbachman parses that previous sentence 18:03:37 lol 18:03:41 tbachman: i meant to say that i didnt think of it, but the concern might be well placed 18:03:47 :) 18:03:55 but other than that the patch looked good to me 18:04:15 :-) 18:04:19 I think I’m good with the new version of the patch 18:04:26 tbachman: ah okay 18:04:45 i know rkukura is probably making his way to this patch after the other patches :-) 18:04:51 I’ll review the latest version ASAP 18:05:07 i would hope to merge this soon since its been on review for a while 18:05:30 perhaps I'll port it first to ocata and verify with nsx gate job 18:05:44 there shouldn't be, but just in case 18:05:55 the gate is currently for ocata only 18:06:11 annak: oh sure, good call 18:06:36 annak: you can proactively backport it 18:06:42 there shouldn't be issues, I meant to say 18:06:47 ok 18:06:53 hopefully there should not be too many changes 18:07:14 and if there are, cherry-picking again to stable/ocata from master is straighforward 18:07:27 yep 18:07:32 i backport even when my patch is not ready so that i dont forget :-P 18:07:44 lol 18:07:45 * tbachman has done that before 18:07:50 so i apologize for the noise that i might be creating in terms of gerrit emails! 18:07:54 (forgotten, that is ;) ) 18:08:03 tbachman: lol 18:08:18 #topic Pending patches 18:08:29 i am just going in top down order 18:08:35 #link https://review.openstack.org/496429 18:08:45 tbachman: annak: thanks for your review on this 18:08:55 SumitNaiksatam: np! 18:08:57 i am happy to discuss this patch or the context here in this meeting 18:09:49 tbachman probably has a little more context than other folks on this 18:10:04 SumitNaiksatam: I’m glad you did this — it’s something I’d had in the back of my mind for a bit, after I found a similar issue 18:10:11 quick summary would be helpful 18:10:12 tbachman: oh cool 18:10:16 s/thanks for doing/I’m blad you did/ 18:10:17 rkukura: sure 18:10:19 er 18:10:22 other way round 18:10:24 tbachman: lol 18:10:28 s/I’m glad you did/thanks for doing/ 18:10:49 rkukura: so i was investigating another issue which was reported by a customer wherein, 18:11:20 in a multi-node neutron server setup, all the neutron servers were getting the same message from the host (opflex) agent 18:12:11 while debugging i realized that GBP policy drivers dont have a way to add the RPC listeners they create, to the RPC workers’ thread that neutron creates and manages 18:12:56 so although Neutron creates, say, 24 RPC workers, the listener setup by, say, the aim_mapping PD was only listening in one thread 18:13:09 or one worker 18:13:49 neutron provides a method (start_rpc_listeners) that needs to be implemented by the core plugin or the service_plugins 18:13:50 ok, but how does using the worker threads prevent the same message from being processed in multiple neutron-server processes, if I understood you correctly? 18:14:26 that is based on the call/cast semantics 18:14:57 so we were getting cast semantics, but using start_rpc_listeners gives us call semantics? 18:15:25 no the issue is much simpler 18:15:25 or is that orthogonal? 18:15:33 yeah that is orthogonal 18:16:03 in the case of call, we want that one of multiple workers be able to pick up the message 18:16:08 I guess if we have cast semantics, multiple worker threads will scale better 18:16:11 but with the GBP PD you could only create one worker 18:16:17 rkukura: right 18:16:38 but GBP PD did not give you an option to do multiple workers 18:16:52 this patch wires up the neutron call all the way to the PD 18:17:16 in case you (as in, the PD) wants to add to the worker pool 18:17:24 ok, so this makes sense, and I guess we should do a separate patch to switch to call semantics for this RPC if necessary 18:17:54 so there was an issue with call versus cast, which i had to fix on the python-opflex side 18:18:05 I guess this patch also makes lifecycle management of the listeners better? 18:18:25 tbachman: yes we are participating in the framework that neutron provides 18:18:26 (since this moves into an RpcWorker 18:18:36 tbachman: right that is my understanding 18:19:07 thanks SumitNaiksatam - that really helps 18:19:19 rkukura: +1k 18:19:21 rkukura: incorrect use of cast versus call turned out to be the original issue that i was investigating 18:19:27 np 18:19:40 #link https://review.openstack.org/491874 18:20:26 tbachman: hi ^^^ 18:20:33 is it ready now? 18:20:35 :) 18:20:47 I think it’s ready for reviews 18:20:53 tbachman: ok thanks 18:21:18 my issues were very minor - I’ll re-review the update ASAP 18:21:31 rkukura: thanks 18:21:40 SumitNaiksatam: ack to rkukura :) 18:21:45 there are a bunch of UI patches that are pending review: 18:21:48 #link https://review.openstack.org/#/q/status:open+project:openstack/group-based-policy-ui+branch:master 18:22:08 i would like to thank marek for posting these patches 18:22:15 sorry, i have been behind 18:22:30 if anyone else in the team wants to take a stab, would appreciate that 18:22:46 the problem we have with gbpui is that there isnt enough regression test support 18:23:12 so you have to try these patches to actually validate 18:23:16 that takes a bit of time 18:23:22 * tbachman nodes 18:23:24 nods 18:23:38 there are some patches from ales as well, and these are more tricky to review 18:24:01 SumitNaiksatam: I haven’t looked at these yet, but hopefully the patch describes the issue and what’s fixed? 18:24:07 or at least this one: 18:24:08 https://review.openstack.org/#/c/493830/ 18:24:15 tbachman: yes :-) 18:24:28 SumitNaiksatam: thx! 18:24:46 tbachman: but thanks for at least showing an inclination to look :-P 18:24:54 lol 18:24:55 i know you reviewed the earlier patch as well 18:25:10 yeah — that was the motivation behind my question ;) 18:25:32 #link https://review.openstack.org/#/q/topic:gbp_fip 18:25:47 I'll take a look though I don't think I ever opened the ui for gbp. Maybe its a good trigger 18:25:56 annak: thanks :-) 18:26:27 tbachman: on those two patches from annak, are we still waiting for something to merge on the apic/aim side? 18:26:43 i meant in stable/ocata 18:27:04 SumitNaiksatam: I think we’re good. I went ahead and rebased them 18:27:05 let me be more specific: 18:27:14 (the stable/ocata ones) 18:27:14 tbachman: oh thanks 18:27:25 so the aim job fails on this: 18:27:27 #link https://review.openstack.org/#/c/496918/ 18:28:06 maybe just a rebase required 18:28:15 just rebased 18:28:30 SumitNaiksatam: thx! 18:28:30 #link https://review.openstack.org/#/c/496917/ 18:28:32 thx 18:28:51 annak: on this ^^^ we are not waiting for your CI, right? 18:29:26 Is there an NSX gate on master? 18:29:38 no, no need to wait 18:29:42 tbachman: i think annak just said no, hence my question 18:29:44 annak: thanks 18:29:45 ah 18:29:47 got it 18:29:48 :) 18:29:54 tbachman: no, I'm trying to wire up one 18:30:01 annak: how is this test different from the other gbp_fip test? 18:30:01 annak: ack. Thx! 18:30:36 SumitNaiksatam: it has --enable_dhcp=False on external network 18:30:50 annak: ah okay, thanks, would have been difficult to catch :-) 18:31:05 and another change related to default GW in static routes, which I'm still looking at on nsx side 18:31:07 annak: come to think of it, i think we can do the same with the other script as well 18:31:13 annak: okay 18:31:34 but i dont think the default gateway needs to be ON for ext networks for the resource_mapping driver either 18:31:44 SumitNaiksatam: so if it ends up as dhcp issue only, should I unify them back? 18:31:45 i guess we are just picking up the default 18:31:58 annak: yes, that would be nice 18:32:15 #link https://review.openstack.org/494299 18:32:27 SumitNaiksatam: ok 18:32:39 SumitNaiksatam: #gate-world-problems 18:32:54 * tbachman notes it passes NSX gate ;) 18:33:01 tbachman: lol 18:33:08 i finished my testing of this ^^^ patch on a live setup (with the aim_mapping driver) and it works 18:33:28 SumitNaiksatam: needs a rebase, I think 18:33:29 with the fixes that come in the patch it can work with any PD (not just aim_mapping) 18:33:33 tbachman: yes i will 18:33:43 but i havent been able to fix the UT issues on this 18:34:08 i dont know how keystone related issues got triggered in the patch because my changes are unrelated 18:34:18 i spent a while but i need to spend some more 18:34:44 #link https://review.openstack.org/#/c/496242/ 18:35:04 tbachman: i guess we have this covered 18:35:17 SumitNaiksatam: ack. rkukura had a good catch there 18:35:23 I am working on addressing that now 18:35:37 * tbachman needs to learn more about alembic migrations :P 18:35:39 tbachman: thanks 18:35:44 rkukura: thanks for the review 18:35:51 SumitNaiksatam: +1k 18:35:53 yes indeed, good catch 18:35:59 np 18:36:08 i believe rkukura did something similar in an earlier patch 18:36:20 believe -> recall 18:36:29 #link https://review.openstack.org/#/c/496855/ 18:37:37 i guess this is straightforward 18:38:00 #link https://review.openstack.org/#/c/491894/ 18:38:11 tbachman: how about that one? 18:38:15 SumitNaiksatam: working on some UTs 18:38:23 ah okay, you had mentioned earlier 18:38:26 I want the router port status to merge before I add the L3 UTs 18:38:27 thanks! 18:38:32 and am working on UTs for the core plugin 18:38:33 right right 18:39:05 okay i think that covers all the patches that need to attention 18:39:11 #topic Open Discussion 18:39:20 nothing from me 18:39:28 * tbachman will not be at the PTG 18:39:30 nor from me.. 18:39:36 just a programming note at my end, i will be on leave starting tomorrow, and will be back on Sept 1st 18:39:47 * tbachman is still pining fo Sydney ;) 18:39:49 yeah, i wont be at the PTG either 18:39:55 tbachman: cool 18:40:07 SumitNaiksatam: cooler if I get to go ;) 18:40:08 lol 18:40:12 I won’t be at PTG 18:40:16 annak: i think you should just come to the bay area, we can do the PTG here :-) 18:40:19 SumitNaiksatam: enjoy the PTO! 18:40:26 tbachman: thanks 18:40:27 lol :) 18:40:42 I will likely come somewhere around january 18:40:47 would be happy to meet 18:40:50 annak: ah okay 18:40:53 right, tbachman and I will both be there the PTG week 18:41:01 * tbachman doesn’t know where annak resides 18:41:04 i was going to say rkukura and tbachman will be coming in Sept 18:41:13 tbachman: Vancouver 18:41:18 annak: nice! 18:41:22 annak: i loved vancouver 18:41:26 * tbachman hails from the Pacific NW 18:41:35 * tbachman gets off-topic 18:41:36 tbachman: there you go! 18:41:46 on your next seattle trip :-) 18:41:48 well the next summit is here :) 18:41:54 annak: oh yeah 18:41:55 :) 18:41:59 may be we should all go 18:42:07 alrighty thanks all 18:42:11 SumitNaiksatam: thanks! 18:42:17 bye! 18:42:18 thanks, bye! 18:42:18 thanks SumitNaiksatam! 18:42:20 bye 18:42:21 #endmeeting