18:01:01 #startmeeting networking_policy 18:01:02 Meeting started Thu Jun 22 18:01:01 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:03 Useful Commands: #action #agreed #help #info #idea #link #topic #startvote. 18:01:05 The meeting name has been set to 'networking_policy' 18:01:29 #info agenda https://wiki.openstack.org/wiki/Meetings/GroupBasedPolicy#June_22nd.2C_15th_2017 18:01:38 annak mentioned she might be late 18:01:45 so lets gets started meanwhile with the agenda 18:02:12 #topic "apic_mapping" driver removal 18:02:28 #link https://review.openstack.org/#/c/476533/ 18:02:51 tbachman: thanks for promptly posting the patch 18:03:05 SumitNaiksatam: np! Sorry about msising some things 18:03:12 tbachman: oh no not all 18:03:35 tbachman: i am good with this patch as soon as the setup.cfg is updated 18:03:54 SumitNaiksatam: I need to fix some UTs 18:04:01 tbachman: if the db migration change is going to take more time, we can wait for that 18:04:11 hi! 18:04:14 SumitNaiksatam: yeah, was also thinking about the DB migrations 18:04:14 tbachman: ah sorry, yeah, those 9 UTs 18:04:22 annak: hi, you made it! 18:04:29 :) 18:04:38 I’m wondering if we want to hold off on the DB migration until we have a plan for how to migrate from the apic mapping to aim mapping drivers 18:04:46 I wasn’t sure how we wanted to handle these - e.g. would we prefer to handle migrations as part of a migration strategy from apic_mapping to AIM 18:04:48 lol 18:04:49 rkukura: ah good, point 18:04:58 rkukura: stole the words from my fingers! 18:04:59 its likely the migration code will need the old DB schema 18:05:13 rkukura: that kind of slipped mind, i completely agree 18:05:54 annak: we are discussing the first topic in the agenda, removal of an older “apic_mapping” policy driver 18:06:25 annak: ideally we should have done this before you started the ocata sync work, as that would have meant less code for you to port 18:07:01 (and would have also meant that we i would have not had to update some of the external repos) 18:07:05 SumitNaiksatam: one weird thing is that I can’t get the same UTs to fail locally 18:07:11 SumitNaiksatam: yes, I don't think i have any more apic tests failing - but if there are, should i ignore issues in apic code? 18:07:35 tbachman: oh, thats never a good thing :-( 18:08:05 annak: there are two apic drivers, if there is anything failing with “apic_mapping” you can ignore 18:08:19 annak: i have been watching the failures on your patch, so i will keep track 18:08:36 ok 18:08:53 annak: hopefully we can merge tbachman’s patch pretty soon (once the UTs are fixed), and that way we can rebase your patch 18:09:00 SumitNaiksatam: as an example, here’s what I see in the logs in the gate: 18:09:01 https://pastebin.com/8Pe4Bh0Y 18:09:06 but I don’t get that locally 18:09:15 so, there’s some trickiness in tracking this down 18:09:26 * tbachman will likely have some fun with pip freeze 18:10:27 tbachman: thats really wierd, and you would wonder why your patch would trigger this 18:10:39 SumitNaiksatam: exactly 18:10:58 I’m wondering if there’s some dependency 18:11:09 like the apic_mapping tests running first imports something that mocks something out 18:11:14 * tbachman waves hands in the air 18:11:29 tbachman: as a sanity need to check annak’s latest patch, if she sees the same error 18:11:45 SumitNaiksatam: the same tests passed in hers 18:11:48 * tbachman had already checked 18:12:05 so, it’s not a generalized problem with upstream 18:12:07 tbachman: ah okay, i should have guessed you had checked ;-) 18:12:20 SumitNaiksatam: you were smart to guess I hadn’t ;) 18:12:47 tbachman: mocking is a good theory, but the failure is in: test_grouppolicy_plugin.TestGroupPolicyPluginMappedGroupResourceAttrs 18:13:15 wonder how removig the apic_mapping driver would affect that 18:13:22 yeah — but 5 test classes were removed 18:13:23 i believe the above tests use a dummy driver 18:13:39 any one of them may have unintentionally patched a class 18:13:46 in neutron 18:13:48 or something 18:13:54 * tbachman continues waving hands in the air 18:14:46 tbachman: could be, but if its a mock it should probably get reset after the test is run 18:15:08 yeah — I’m not sold on my theory… but atm, it’s all I have to go on 18:15:34 i also meant to clean up the logging in the master/newton so that these things would be easier to debug from the gate logs 18:15:53 similar to in mitaka, but the same changes are not working 18:16:21 anyway, tbachman seems like you are able to dig out the exception from the console logs 18:16:30 SumitNaiksatam: ack 18:16:38 there’s another, but it doesn’t appear in the other tests 18:16:47 https://pastebin.com/SWVmkqFJ 18:17:01 in short, I need to keep digging 18:17:06 but the first one appears in multiple failures 18:17:11 which is why I think it’s the culprit 18:17:40 tbachman: okay, we can follow up online, unless rkukura or annak have any suggestions to offer on tracking these down 18:17:50 s/online/offline/ 18:18:31 tbachman: thanks :-) 18:18:38 SumitNaiksatam: np! 18:18:54 you can tell i am distracted, just moved to a conf room 18:18:56 tbachman: I’ll take a closer look and let you know if I think of anything 18:19:03 rkukura: thx! 18:19:19 changing the agenda order 18:19:22 #topic Ocata sync 18:19:32 #link https://review.openstack.org/#/q/topic:ocata_sync 18:19:49 annak: just noticed that you are down to 4 UT failures, nice! 18:20:00 annak: awesome! 18:20:08 yes, not sure all the fixes are good though 18:20:36 I see different notification patterns, probably due to rewritten get_session patch 18:20:47 oh but the devstack jobs are still broken 18:21:03 annak: once we get those to pass, we will have much much better confidence 18:21:15 (though the devstack patches dont test the data path) 18:21:52 lets start with the UTs first, annak do you think you have these under control, or you need help? 18:21:56 yes, I didn't look at devstack jobs yet 18:22:23 i was just going to say you might have not had a chance to look at the latest failures 18:22:29 I'll need some help verifying I'm doing the right thing :) 18:22:40 annak: yes of course :-) 18:23:34 I can write an email summarizing the issues I'm uncertain with 18:23:46 annak: have you had a chance to look at the devstack job failures or is that related to the “different notification patterns, probably due to rewritten get_session patch” you mentioned? 18:23:51 annak: okay email is good 18:24:26 no, I saw the plugin fails to load in all the devstack jobs, I didn't run one locally to understand why 18:24:33 (yet) 18:25:17 annak: okay, i will take a look at the logs and there is enough information there, hopefully we dont have to run those locally to debug 18:25:37 ok thanks 18:26:02 i meant to say, i hope there is enough information there :-) 18:26:52 yeah, I didn't find any but maybe I didn't look in right places 18:27:11 annak: once tbachman’s patch is merged, and a few more small changes after that, we feel that we can remove the dependency on some of the external apic packages 18:27:32 sounds great 18:28:08 #topic Subnetpools in resource_mapping driver 18:28:14 #link https://review.openstack.org/469681 18:28:23 annak: thanks for your summary email 18:28:51 unfortunately, i dont have had a chance to dwell any more on it 18:29:02 annak: sorry for not responding — I also need to think on it 18:29:14 tbachman: thanks 18:29:15 (and thanks for writing that up) 18:29:31 annak: i think the ocata sync is higher priority 18:29:48 so we can keep thinking about this in parallel 18:29:59 ok 18:30:28 I tried doing the "relax neutron limitation" patch, I think it works ok 18:30:43 annak: okay, good data point 18:30:51 But I realized that even if we manage to get it in, it won't be backported 18:31:15 so if we go in that direction we'll need to patch GBP with it anyway 18:31:23 annak: yeah 18:31:58 rkukura: did you have a chance to think about this further? 18:32:10 no, but I’d like to 18:32:41 rkukura: okay 18:33:09 songole has not joined today, last week he mentioned he would come back with confirmation on how the VPN service uses the proxy-pool 18:33:58 in the absence of his input we will assume that our understanding was correct, the proxy-pool is only internally significant 18:35:06 if we havent thought about this further, i propose that we think about this offline, and perhaps exchange emails to make progress until the next meeting 18:35:17 * tbachman nods 18:35:20 ok 18:35:24 tbachman: rkukura thanks 18:35:42 annak: thanks for your great work on both these things! 18:35:52 SumitNaiksatam: np :) 18:36:09 annak: hopefully we can all make a collective push to get your Ocata sync patch ready soon 18:36:17 #topic Open Discussion 18:36:25 that would be great 18:36:41 tbachman: you will be taking a well deserved vacation next week? 18:36:45 lol 18:36:55 SumitNaiksatam: not sure it’s well-deserved, but taking one, yes ;) 18:37:04 tbachman: lol 18:37:23 tbachman: rkukura: hopefully we can merge tbachman’s patch before that 18:37:33 assuming tbachman has the time to wrap it up 18:37:35 makes sense 18:37:39 SumitNaiksatam: hoping I do 18:37:48 i think we have already decided that the db migration is not needed in this patch 18:37:54 SumitNaiksatam: ack 18:37:55 tbachman: thanks a bunch! 18:38:05 SumitNaiksatam: np…. but thank me when it’s done ;) 18:38:29 tbachman: its getting there :-) 18:38:31 close 18:38:43 if nothing else we can wrap up for now 18:38:47 I'd appreciate attention to the vmware patch ;) https://review.openstack.org/#/c/453925/ 18:38:49 It wouldn’t hurt to add comments to existing DB models that they are going away 18:39:01 rkukura: sure 18:39:03 thanks tbachman for the comments 18:39:04 rkukura: good point - could you add that to the review? 18:39:06 annak: np! 18:39:13 unless its completely obviuous they are apic_mapping only, of course 18:39:14 Will have another look as well 18:39:22 annak: absolutely, dont worry about that, we will review and get that in, did notice that its out of WIP 18:39:36 thx! 18:40:08 annak: i thought you earlier mentioned that your dirver needed the ocata sync to complete, si there no such dependency? 18:40:24 its needed to create the gate job 18:40:39 annak: ah okay, sorry i misunderstood 18:40:51 but for the UT its good as is 18:41:06 annak: that understanding was one of the reasons i was trying to push to getting the ocata sync completed 18:41:33 yes, we need ocata soon for sure, that understanding is correct :) 18:41:41 okay 18:42:18 anything else for today? 18:42:30 not from me 18:42:46 alrighty, thanks all for joining 18:42:53 SumitNaiksatam: thanks! 18:42:55 bye until the next time 18:42:58 thanks! bye 18:43:04 #endmeeting