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