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