18:06:57 #startmeeting networking_policy 18:06:58 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 Useful Commands: #action #agreed #help #info #idea #link #topic #startvote. 18:07:02 The meeting name has been set to 'networking_policy' 18:07:10 thanks fungi ! 18:07:10 fungi: there you go thanks :-) 18:07:22 i will be careful in the future 18:07:44 my pleasure 18:08:13 #topic UT failures reported on Xenial 18:08:26 #link http://lists.openstack.org/pipermail/openstack-dev/2016-July/099138.html 18:08:57 this was reported a couple of days back 18:09:08 and some of us have been trying to get the bottom on this 18:09:35 clarkb: thanks for pointing us to this, and the updates thereafter 18:09:59 Ohai. Its possible I tracked down what was causing that locally 18:10:06 and will have to see if dougwig also has a similar issue 18:10:13 clarkb: ah ok, the host name thingy? 18:10:17 tests are currently running to cofirm or deny this will let you know 18:10:24 clarkb: sure 18:10:36 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 so I had an /etc/hostname but no entries for it in /etc/hosts 18:11:44 clarkb: ah okay 18:11:55 i'm sure my /etc/hosts is wrong. 18:12:58 dougwig: wrong as in not populated or inconsistent entries? 18:13:31 not populated. 18:13:34 dougwig: ah ok 18:13:40 only fails on first run, with all tests. subsequent runs pass. 18:13:43 it's a weird bug. 18:13:58 dougwig: clarkb: i am just comparing with my setup 18:14:04 it's something in the setup phase of neutron testlib, not gbp. 18:14:05 i picked up the default hostname 18:14:46 and my /etc/hosts and /etc/hostname seem to be populated correctly 18:14:57 but i am still seeing the issue when i run the tests in parallel 18:15:32 dougwig: we were explicitly setting the testlib_api._TABLES_ESTABLISHED in one place, and we removed that 18:17:33 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 SumitNaiksatam: yes 18:17:55 clarkb: okay 18:19:22 shouldn’t that be 127.0.0.1? 18:19:33 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 rkukura: good catch, i did not change that 18:19:55 rkukura: SumitNaiksatam it depends is the answer 18:20:08 ubuntu + dnsmasq + network manager use 127.0.1.1 18:20:10 I don't know why 18:20:26 clarkb: ah okay, mu localhost is 127.0.0.1 18:20:34 either way should work since that entire /8 is absically the same thing 18:20:52 (on linux) 18:20:58 clarkb: okay 18:21:07 could them being different IPs break something somewhere? 18:24:15 rkukura: i can try to make it consistent, just to rule any other bug out 18:25:37 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 rkukura: okay 18:26:17 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 sorry, was on phone. reading scrollback 18:26:31 dougwig: np 18:27:06 when was that test change merged? 18:28:13 dougwig: #link http://git.openstack.org/cgit/openstack/group-based-policy/commit/?id=696005faaee1670083fe921325399e4607a4ab20 18:29:26 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 dougwig: :-) 18:30:04 dougwig: you are brave 18:30:23 dougwig: i believe we dont have any more explicit references to testlib_api 18:30:40 i'm fairly certain that it's not a gbp root issue, based on the failure paths. 18:31:04 dougwig: okay 18:33:10 rkukura: hemanthravi: since this is a burning issue, i dont have anything else of higher priority to discuss today 18:33:49 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 SumitNaiksatam: no 18:34:58 dougwig: i saw an email from the vmware-NSX folks earlier today saying their tests are passing 18:35:07 dougwig: do you happen to know if they had to change anything? 18:35:27 it did not seem like they had to 18:35:30 https://review.openstack.org/#/c/327033, making changes to make this restrictive 18:35:42 hemanthravi: yes, saw the update earlier today 18:35:49 running into a test failure, will send out an email once this is resolved 18:36:00 hemanthravi: it will be good for ivar to take a look at this since he was asking me about it earlier 18:36:05 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 update on the config pathces, working on moving them to contrib and should be done in 2-3 days 18:36:28 hemanthravi: okay, looking forward to those 18:36:38 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 dougwig: although we removed the explicit reference, we might still be using via some inheritence hierarchy 18:37:18 dougwig: the tests on which this fails, we are explicitly calling the create_all 18:37:42 dougwig: the other wierd thing is that it sometimes fails in the clean_up 18:38:12 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 dougwig: where it tries to clean up a table, which presumably it thinks exists, but that table doesnt 18:39:45 dougwig: looking for an example to point to you 18:41:19 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 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 #endmeeting