18:01:48 #startmeeting networking_policy 18:01:49 Meeting started Thu Mar 15 18:01:48 2018 UTC and is due to finish in 60 minutes. The chair is SumitNaiksatam. Information about MeetBot at http://wiki.debian.org/MeetBot. 18:01:50 Useful Commands: #action #agreed #help #info #idea #link #topic #startvote. 18:01:52 The meeting name has been set to 'networking_policy' 18:01:54 hi rkukura! 18:02:04 (continuing the discussion about summit) 18:02:11 annakk: did you have any other talks? 18:02:17 no 18:02:48 bummer, but thats fine, its still in your backyard so you can attend regardless :-) 18:03:06 yes, hope to see you all there as well! 18:03:07 #topic Master branch gate breakage 18:03:41 so I think this change is something that is causing an issue: 18:03:48 #link https://github.com/openstack/neutron/commit/4a0200a2d4e9fdedfc1b74c12330b3b4ee1a70ed 18:04:18 i am wondering if we have to do the same thing in our project 18:05:17 SumitNaiksatam: seems likely 18:05:36 so i will try it out, but hopefully the stable branches are not blocked (after anna’s patch was merged) 18:05:55 *anna’s patches on the stable branches 18:06:25 #topic Pending patches 18:06:40 happy to see this new driver patch from anna’s team: 18:06:57 #link https://review.openstack.org/552902 18:07:29 annakk: if you feel comfortable we can quickly discuss this now 18:07:54 but no pressure we can do it later as well on gerrit 18:08:13 sure, just some context - the nsx policy platform is out with new version 18:08:36 old version APIs were marked experimental, so we'll not support them with gbp going forward 18:08:58 annakk: thats fine 18:09:17 there were some significant changes on platform side, so we'll do some refactoring in gbp driver and in nsxlib which wraps platform apis 18:09:27 annakk: okay 18:09:38 annakk: you will be enabling the NSX gate job on the master branch? 18:10:25 that's challenging, since gates are assuming that all components share same branch 18:10:35 but hopefully we'll do that 18:10:37 other option is you immediately backport to stable/pike while still in review 18:10:50 that way we can see the result on stable/;pike 18:10:57 yes, that's the plan for now 18:11:03 okay cool 18:11:05 that works 18:11:18 annakk: Is your plan to move the stable branches to the new API or leave them on the old API? 18:11:47 my understanding is the old driver is being removed from the stable branches as well? 18:11:52 pike will go with new one, probably ocata as well 18:12:20 annakk: ok 18:12:41 i know rkukura is not going to like it, but perhaps if this is not disruptive to anyone i am fine removing it from stable branches as well 18:13:23 * tbachman wonders if there are are a lot of UTs for the old one 18:13:43 few dozen UTs I think 18:13:56 I’m flexible 18:14:02 k — just thinking whether we’ll save much gate time there :) 18:14:04 I think it should be easy enough to backport everything, hopefully we'll be only touching code under nsx* 18:14:05 (and when i say “rkukura not going to like it” i mean its all for very valid reasons) 18:14:56 the other big patch pending review is rkukura’s #link https://review.openstack.org/#/c/529991/ 18:15:05 although that one is apic specific 18:15:10 right 18:15:42 * tbachman needs to review that patch, too 18:15:53 rkukura: sorry for asking again, but you earlier mentioned that your UTs are triggering this for now 18:16:18 SumitNaiksatam: not sure what you are asking 18:16:18 in a real deployment, how will this validation and repair kick in? 18:16:40 initial plan is for a CLI that is run manually, or could be run from cron, etc. 18:17:19 so those dont need to be part of this patch and/or posted in parallel, so that say, we can exercise it from the AIM gate job? 18:17:23 I’m trying to get it to the point where validation would pass for a neutron-only (no GBP) deployment 18:17:54 I do think we will want to run it from the AIM job when it is ready to handle everything deployed in that job 18:18:33 I’d prefer to merge the initial version without the CLI, hopefully begining of next week 18:18:59 then add the CLI, and eventually call the CLI from the AIM gate job 18:19:23 rkukura: so by that you mean, if GBP is triggering creation of Neutron resources, the current state of the tool will not be able to validate/repair those Neutron resources? 18:20:23 There are cases where GBP PD modifies AIM resources owned by Neutron resources, and those would fail 18:20:44 okay 18:21:03 And where GBP creates AIM resources that would be unexpected from Neutron’s point of view 18:21:45 one point might be worth mentioning 18:22:29 there is a test_aim_validation UT class that tests that all the various AIM resource types can be validated and repaired 18:22:45 okay 18:23:20 rkukura: so the aim gate job runs an exercise script and cleans up the resources after that 18:23:24 But I am also adding _validate() calls to many existing AIM UTs. These don’t attempt to break/repair anything, just make sure everything passes validation 18:23:41 so potentially you could your own testing after that 18:23:53 *could add 18:24:08 These _validate() calls will add some execution time to those UTs, but I think this is better than duplicating complext scenarios in the test_aim_validation UTs 18:25:13 SumitNaiksatam: In the AIM gate job, I think the main goal would be to make sure things we already do pass validation, not necessarily to test repairs. That might be added later. 18:26:43 so keeping in mind the running time of the py27 gate job, if adding this validation tips it over, it might be something you can consider adding to the aim gate job instead 18:27:19 SumitNaiksatam: Agreed, but we need to make sure UTs catch changes that would break validation when possible 18:27:32 good point 18:27:52 the other patches we have in review are related to the effort around integrating with SFC but still centered around apic 18:27:58 these are mostly bug fixes 18:28:09 #topic Open Discussion 18:28:23 anything else we need to discuss today? 18:28:51 not from me 18:28:56 I’m good 18:29:00 i was working on optmizing the execution time of at least one of our critical functions 18:29:09 had a good chat with rkukura on taht 18:29:11 SumitNaiksatam: Any chance we’ll be able to get either more CPU cores or more time for stable branch gate jobs? 18:29:30 was surprised some of the unnecessary things we do 18:29:36 will report more details next time around 18:29:57 things will can run in milli seconds are running in the order of seconds 18:29:58 anyway 18:30:07 rkukura: honestly, i have never tried 18:30:32 SumitNaiksatam: sounds promising! 18:30:59 i have a physcological barrier asking that question :-( 18:31:46 SumitNaiksatam: We definitely treat the stable branches differently than other projects, so I understand 18:32:26 rkukura: tbachman lets discuss that when you guys here, next week? 18:32:36 SumitNaiksatam: we’re there the following week 18:32:39 the week of the 25th 18:32:40 right 18:32:44 ah okay, cool 18:32:53 alrighty, lets wrap up for today then 18:32:56 Monday-Thurday for me 18:32:58 thanks for joining 18:33:00 Thursday 18:33:02 rkukura: sam 18:33:04 same 18:33:06 SumitNaiksatam: thx! 18:33:10 rkukura: tbachman great 18:33:13 bye! 18:33:16 #endmeeting