18:06:57 <SumitNaiksatam> #startmeeting networking_policy
18:06:58 <openstack> Meeting started Thu Jul 14 18:06:57 2016 UTC and is due to finish in 60 minutes.  The chair is SumitNaiksatam. Information about MeetBot at http://wiki.debian.org/MeetBot.
18:07:00 <openstack> Useful Commands: #action #agreed #help #info #idea #link #topic #startvote.
18:07:02 <openstack> The meeting name has been set to 'networking_policy'
18:07:10 <rkukura> thanks fungi !
18:07:10 <SumitNaiksatam> fungi: there you go thanks :-)
18:07:22 <SumitNaiksatam> i will be careful in the future
18:07:44 <fungi> my pleasure
18:08:13 <SumitNaiksatam> #topic UT failures reported on Xenial
18:08:26 <SumitNaiksatam> #link http://lists.openstack.org/pipermail/openstack-dev/2016-July/099138.html
18:08:57 <SumitNaiksatam> this was reported a couple of days back
18:09:08 <SumitNaiksatam> and some of us have been trying to get the bottom on this
18:09:35 <SumitNaiksatam> clarkb: thanks for pointing us to this, and the updates thereafter
18:09:59 <clarkb> Ohai. Its possible I tracked down what was causing that locally
18:10:06 <clarkb> and will have to see if dougwig also has a similar issue
18:10:13 <SumitNaiksatam> clarkb: ah ok, the host name thingy?
18:10:17 <clarkb> tests are currently running to cofirm or deny this will let you know
18:10:24 <SumitNaiksatam> clarkb: sure
18:10:36 <clarkb> yes, my local setup did not use config drive whcih glean in the infra images depends on to set the hostname properkly
18:10:47 <clarkb> so I had an /etc/hostname but no entries for it in /etc/hosts
18:11:44 <SumitNaiksatam> clarkb: ah okay
18:11:55 <dougwig> i'm sure my /etc/hosts is wrong.
18:12:58 <SumitNaiksatam> dougwig: wrong as in not populated or inconsistent entries?
18:13:31 <dougwig> not populated.
18:13:34 <SumitNaiksatam> dougwig: ah ok
18:13:40 <dougwig> only fails on first run, with all tests.  subsequent runs pass.
18:13:43 <dougwig> it's a weird bug.
18:13:58 <SumitNaiksatam> dougwig: clarkb: i am just comparing with my setup
18:14:04 <dougwig> it's something in the setup phase of neutron testlib, not gbp.
18:14:05 <SumitNaiksatam> i picked up the default hostname
18:14:46 <SumitNaiksatam> and my /etc/hosts and /etc/hostname seem to be populated correctly
18:14:57 <SumitNaiksatam> but i am still seeing the issue when i run the tests in parallel
18:15:32 <SumitNaiksatam> dougwig: we were explicitly setting the testlib_api._TABLES_ESTABLISHED in one place, and we removed that
18:17:33 <SumitNaiksatam> clarkb: i have: “127.0.1.1       ubuntu” in my /etc/hostnames and /etc/hosts has “ubuntu”, so that should be good, right?
18:17:50 <clarkb> SumitNaiksatam: yes
18:17:55 <SumitNaiksatam> clarkb: okay
18:19:22 <rkukura> shouldn’t that be 127.0.0.1?
18:19:33 <SumitNaiksatam> clarkb: dougwig: i just realized that we could have experimental gate jobs for Xenial, so i am going to post a patch to get that started for GBP right after this meeting
18:19:44 <SumitNaiksatam> rkukura: good catch, i did not change that
18:19:55 <clarkb> rkukura: SumitNaiksatam it depends is the answer
18:20:08 <clarkb> ubuntu + dnsmasq + network manager use 127.0.1.1
18:20:10 <clarkb> I don't know why
18:20:26 <SumitNaiksatam> clarkb: ah okay, mu localhost is 127.0.0.1
18:20:34 <clarkb> either way should work since that entire /8 is absically the same thing
18:20:52 <clarkb> (on linux)
18:20:58 <SumitNaiksatam> clarkb: okay
18:21:07 <rkukura> could them being different IPs break something somewhere?
18:24:15 <SumitNaiksatam> rkukura: i can try to make it consistent, just to rule any other bug out
18:25:37 <rkukura> On my ubuntu system, ‘ip addr’ and /etc/hosts both use 127.0.0.1, so I’d try making these match
18:25:47 <SumitNaiksatam> rkukura: okay
18:26:17 <SumitNaiksatam> clarkb: dougwig: so if you have any further thoughts on this please do let us know, otherwise we will keep plugging at this and see how far we get
18:26:25 <dougwig> sorry, was on phone.  reading scrollback
18:26:31 <SumitNaiksatam> dougwig: np
18:27:06 <dougwig> when was that test change merged?
18:28:13 <SumitNaiksatam> dougwig: #link http://git.openstack.org/cgit/openstack/group-based-policy/commit/?id=696005faaee1670083fe921325399e4607a4ab20
18:29:26 <dougwig> looking on my test host, i do not see gbp unit failures. mine were in networking-cisco.  i think i was running all three at the same time, making my slow VM cry.
18:29:50 <SumitNaiksatam> dougwig: :-)
18:30:04 <SumitNaiksatam> dougwig: you are brave
18:30:23 <SumitNaiksatam> dougwig: i believe we dont have any more explicit references to testlib_api
18:30:40 <dougwig> i'm fairly certain that it's not a gbp root issue, based on the failure paths.
18:31:04 <SumitNaiksatam> dougwig: okay
18:33:10 <SumitNaiksatam> rkukura: hemanthravi: since this is a burning issue, i dont have anything else of higher priority to discuss today
18:33:49 <SumitNaiksatam> rkukura: hemanthravi: if there is nothing else, we can wrap early today and i can go back to digging more into this issue
18:34:51 <hemanthravi> SumitNaiksatam: no
18:34:58 <SumitNaiksatam> dougwig: i saw an email from the vmware-NSX folks earlier today saying their tests are passing
18:35:07 <SumitNaiksatam> dougwig: do you happen to know if they had to change anything?
18:35:27 <SumitNaiksatam> it did not seem like they had to
18:35:30 <hemanthravi> https://review.openstack.org/#/c/327033, making changes to make this restrictive
18:35:42 <SumitNaiksatam> hemanthravi: yes, saw the update earlier today
18:35:49 <hemanthravi> running into a test failure, will send out an email once this is resolved
18:36:00 <SumitNaiksatam> hemanthravi: it will be good for ivar to take a look at this since he was asking me about it earlier
18:36:05 <dougwig> i think it's timing/order/load related, so running it once and seeing it work is unfortunately not a great repro test.  but not using testlib anymore probably shields you entirely.
18:36:17 <hemanthravi> update on the config pathces, working on moving them to contrib and should be done in 2-3 days
18:36:28 <SumitNaiksatam> hemanthravi: okay, looking forward to those
18:36:38 <dougwig> the bug is because create_all isn't being called to populate the tables in the in memory sqlite, which is entirely a testlib/sqltestcase thing.
18:37:02 <SumitNaiksatam> dougwig: although we removed the explicit reference, we might still be using via some inheritence hierarchy
18:37:18 <SumitNaiksatam> dougwig: the tests on which this fails, we are explicitly calling the create_all
18:37:42 <SumitNaiksatam> dougwig: the other wierd thing is that it sometimes fails in the clean_up
18:38:12 <dougwig> oh i see, so you're not using the setup/teardown logic in the underlying class?  interesting.  do the same calls happen?
18:38:12 <SumitNaiksatam> dougwig: where it tries to clean up a table, which presumably it thinks exists, but that table doesnt
18:39:45 <SumitNaiksatam> dougwig: looking for an example to point to you
18:41:19 <SumitNaiksatam> dougwig: here is an example: #link http://git.openstack.org/cgit/openstack/group-based-policy/tree/gbpservice/neutron/tests/unit/services/grouppolicy/test_apic_mapping.py?id=696005faaee1670083fe921325399e4607a4ab20#n130
18:44:21 <SumitNaiksatam> clarkb: dougwig: rkukura: i will end this GBP meeting now, but both, rkukura and I will continue to pursue this, and will be around to discuss
18:44:35 <SumitNaiksatam> #endmeeting