16:00:22 #startmeeting neutron_ci 16:00:24 Meeting started Tue Nov 14 16:00:22 2017 UTC and is due to finish in 60 minutes. The chair is ihrachys. Information about MeetBot at http://wiki.debian.org/MeetBot. 16:00:26 Useful Commands: #action #agreed #help #info #idea #link #topic #startvote. 16:00:28 The meeting name has been set to 'neutron_ci' 16:00:40 hi all 16:00:56 hello 16:00:59 we skipped the last time because of summit but now we are hopefully back to business 16:01:17 giving people some time to join 16:01:28 hi 16:01:33 o/ 16:01:40 sorry for joining late 16:02:43 o/ 16:03:01 ok let's get it started 16:03:06 #topic Actions from prev meeting 16:03:11 we had a single one 16:03:16 "ihrachys to follow up with Chandan about tempest split again" 16:03:22 I guess I can update on that here 16:03:50 so we prepared the new repo after cookie cutting it: v 16:03:51 https://review.openstack.org/506553 16:04:03 * mlavalle got confused with the falling back to standard time 16:04:10 also added -nv jobs in neutron repo: https://review.openstack.org/516934 16:04:55 there is a follow up on the patch adding jobs here: https://review.openstack.org/519649 removing -api job from gate pipeline (it's just cosmetic, the job is not triggered by zuul) 16:05:42 also, Chandan has a patch inheriting those new jobs in the new repo: https://review.openstack.org/519646 16:06:13 once it's all done, next steps are syncing latest test code from neutron repo to the new one: https://review.openstack.org/519310 (still WIP) 16:06:40 Nice progress! 16:06:42 then we'll enable voting for new jobs, remove legacy jobs, and finally clean up neutron tree from tempest code 16:07:14 I want to block all patches for tempest code after we land the sync patch 16:07:26 ++ 16:07:37 basically go through all patches touching neutron/tests/tempest/... and -2 them until the code is spun into the new repo 16:08:09 I *think* we haven't missed anything in the list of tasks, but if you see a gap, feel free to tell 16:08:21 maybe we'll need to update our docs somewhere to reflect the new location of tests 16:08:22 will do 16:08:34 That is a good idea 16:08:58 so new "workflow" will be to add tempest tests after patch to neutron is merged, right? 16:09:15 or will be any way to do it "in parallel"? 16:09:18 slaweq, kinda. you can post a patch with depends-on 16:09:24 ahh, ok 16:09:26 and reviewers can enforce the patch present 16:09:44 also note that the new repo is meant for pike only 16:10:03 so if you let's say want to get it in an earlier release, you gotta backport it to neutron repo 16:10:19 ok, good to know, thx 16:10:19 in the future, new releases will all be covered by the new repo 16:10:28 but we start with current master only 16:11:00 makes sense 16:11:32 #topic Grafana 16:11:35 http://grafana.openstack.org/dashboard/db/neutron-failure-rate 16:12:41 nothing of special interest there it seems 16:12:56 ryu periodic has failed twice though 16:14:44 which is weird, I can't see any failures in http://logs.openstack.org/periodic/legacy-periodic-tempest-dsvm-neutron-with-ryu-master/ 16:15:43 I guess some fluke in data 16:16:06 #topic Fullstack 16:16:24 so this landed: https://review.openstack.org/#/c/517598/ 16:16:36 which should hopefully make trunk test fixed 16:17:00 thanks slaweq :-) 16:17:11 I hope it helps 16:17:26 (taking random failure) http://logs.openstack.org/13/518113/1/check/legacy-neutron-dsvm-fullstack/08c6be8/logs/testr_results.html.gz 16:17:35 it seems to pass 16:17:45 though there are still failures there 16:18:00 good to hear that it passes 16:18:51 it seems that those connectivity/sg failures are now the new constant. here is another log with the same: http://logs.openstack.org/51/396351/43/check/legacy-neutron-dsvm-fullstack/6f49eec/logs/testr_results.html.gz 16:19:14 in the latter log, see how test_north_south_traffic failed 16:19:23 it failed waiting for port active 16:20:12 and here is what I see in dhcp agent: http://logs.openstack.org/51/396351/43/check/legacy-neutron-dsvm-fullstack/6f49eec/logs/dsvm-fullstack-logs/TestLegacyL3Agent.test_north_south_traffic/neutron-dhcp-agent--2017-11-14--10-37-54-629926.txt.gz?level=TRACE#_2017-11-14_10_38_37_370 16:20:17 RuntimeError: Second simultaneous read on fileno 9 detected 16:20:23 afair it's eventlet issue 16:20:40 like when something is not monkey patched 16:20:59 and it happens when calling to rootwrap 16:21:32 also, this error does seem like a logic bug in neutron: http://logs.openstack.org/51/396351/43/check/legacy-neutron-dsvm-fullstack/6f49eec/logs/dsvm-fullstack-logs/TestLegacyL3Agent.test_north_south_traffic/neutron-dhcp-agent--2017-11-14--10-37-54-629926.txt.gz?level=TRACE#_2017-11-14_10_39_57_401 16:21:47 seems like we pass mac address of None there into netaddr 16:22:40 the first one should be fixed by https://review.openstack.org/#/c/514547/, is that right? 16:22:44 I believe for the eventlet issue, the following patch may help: https://review.openstack.org/#/c/514547/ 16:22:48 jlibosva, yeah :) 16:23:30 and afaiu it also helps the issue with obsolete data left in buffer when we raise Timeout 16:23:51 toshii explained there why it's so 16:24:31 if we don't unset need_restart flag, it means we raised an error, so we force restart which makes it clean up the socket 16:25:02 thoughts? 16:25:36 we should get some oslo cores, that's what I think :) 16:25:45 yeah 16:26:38 #action ihrachys to pull oslo folks into reviewing rootwrap patch 16:27:19 as for mac address being None, I think we still should fix it. 16:27:32 even though maybe it wouldn't show up without eventlet issue 16:27:40 the L3 subteam can take a look 16:28:08 mlavalle, ok cool 16:28:13 I can bring it up on Thursday 16:28:30 #action mlavalle to track down "TypeError: None is not str() or unicode()!" error in dhcp agent fullstack tests 16:28:38 isn't the second only a consequence? it failed to create a namespace so then later it didn't add a device 16:28:41 mlavalle, I put you personally on the hook ;) 16:28:47 that's ok 16:28:53 LOL 16:29:00 jlibosva, probably, but passing bad data into a lib is bad taste 16:29:12 yeah, it usually is :-) 16:30:01 ok, I think it's enough for fullstack. as usual, we will revisit next time when we make progress on rootwrap. 16:30:52 #topic Scenarios 16:31:25 I take a random recent failure 16:31:37 http://logs.openstack.org/95/518395/2/check/neutron-tempest-plugin-dvr-multinode-scenario/da8637d/logs/testr_results.html.gz 16:31:50 timeout in test_east_west 16:31:59 afair there was a bug for that 16:32:23 maybe https://bugs.launchpad.net/neutron/+bug/1717302 16:32:23 Launchpad bug 1717302 in neutron "Tempest floatingip scenario tests failing on DVR Multinode setup with HA" [High,Confirmed] 16:33:32 logs service just dumped on me. is it working for everyone? 16:34:01 not for me :/ 16:34:14 yeah just hanging here 16:34:25 mlavalle, hard to say since I don't have logs. :) 16:34:35 not responding to me either 16:34:37 mlavalle, but speaking of that, do we have progress on the bug? 16:34:50 it works again 16:35:03 I don't know, Swami was working on that one and he was in Sydney last week 16:35:32 I will get update in the L3 meeting on Thursday 16:35:37 ok. I also saw some weird security groups failure that seemed api layer related once but now I don't have it 16:35:44 could be it was fixed or smth 16:35:59 it was smth like api layer spilling an error on request validation 16:36:15 slaweq, not for me 16:37:24 ok there is little we can do without log server here. I will report the SG api bug if I see it again. 16:38:22 there was also this bug that affected the job: https://bugs.launchpad.net/neutron/+bug/1719711 16:38:22 Launchpad bug 1719711 in neutron "iptables failed to apply when binding a port with AGENT.debug_iptables_rules enabled" [High,Confirmed] - Assigned to Brian Haley (brian-haley) 16:38:23 yeah, logs don't work yet for me either 16:39:34 haleyb, was there any progress on that one? 16:39:37 no fix for ^^ yet btw 16:40:01 do we have an idea what happens there? 16:41:02 not yet, don't know how they got out of sync 16:42:23 ok. if you feel like you won't have time for it in next weeks, feel free to unassign so that we can find someone to pick it 16:43:23 btw seems like log server is actually working but very slow 16:43:26 #topic zuulv3 job migration 16:43:33 mlavalle, your floor 16:44:00 I got https://review.openstack.org/#/c/516715/ reviewed by yamamoto 16:44:18 I will need to rebase, now that the tempest patch merged 16:44:35 once I do that, I will need another +2 16:45:05 and I will complete the entire process with the two related patchsets 16:45:27 https://review.openstack.org/#/c/516724/ 16:45:44 and https://review.openstack.org/#/c/516744/ 16:46:06 once I complete this, I will migrate the other jobs 16:46:09 left 16:46:19 that's all I have for today 16:46:34 mlavalle, ok. how does it fit the narrative of moving the code of tempest into the new repo? 16:46:40 seems like we already have a job for api no? 16:46:44 that uses the new repo 16:46:59 I hadn't thought of that 16:47:02 so when we switch to it as voting, we won't need the legacy flavor 16:47:28 then we remove the legacy one I guess 16:47:41 so it could be that moving it around is not very useful if we get rid of it in next weeks 16:47:53 we could as well remove it from project-config right away 16:48:01 that being said... the new jobs are for master only 16:48:09 we still need legacy jobs for stable 16:48:17 how does it work in terms of branches? 16:48:30 do we keep both jobs in master? backport jobs to stable? 16:48:48 don't know, need to think about it 16:49:56 yeah. ok that's cool with me. in general, maybe fullstack or functional would be better candidates to start since we don't reshuffle them right now 16:50:19 good suggestion 16:51:42 #topic Open discussion 16:51:53 if you have a topic, bring it on 16:52:00 also, patches to peek at are welcome 16:52:48 there is still this patch lacking attention https://review.openstack.org/#/c/514660/ 16:52:50 do we want it? 16:53:25 oh right. I think it makes sense to have it. 16:53:48 zuul is nuts there 16:53:51 prolly to recheck 16:54:03 rechecked 16:54:16 yeah, I was about to say 16:54:17 mlavalle, maybe you can have a look at it, it's small ^ 16:54:31 yeap, will review today 16:54:44 I will be happy if we don't every use it in tree, it would still be helpful to have it. 16:55:16 LOL, we both rechecked it 16:55:20 ok. I also gonna advertise a new scenario for availability zones: https://review.openstack.org/#/c/509156/ 16:56:01 mlavalle, thankfully zuul is smart enough not to run it twice 16:56:04 anything else? 16:56:14 or you have your full 3 minutes of free time! 16:56:21 \o/ 16:56:24 thrilled? 16:56:31 :) 16:56:33 #endmeeting