14:01:56 #startmeeting neutron_upgrades 14:01:57 Meeting started Thu Aug 3 14:01:56 2017 UTC and is due to finish in 60 minutes. The chair is ihrachys. Information about MeetBot at http://wiki.debian.org/MeetBot. 14:01:58 Useful Commands: #action #agreed #help #info #idea #link #topic #startvote. 14:02:01 The meeting name has been set to 'neutron_upgrades' 14:02:14 o/ 14:02:18 o/ 14:02:54 this week we'll make it short because we are in freeze mode and some of us are mostly consumed by pre-release stuff 14:03:15 to recap, the freeze started prev week 14:03:28 and we are looking at Aug 07 - Aug 11 to get first RC1 14:03:37 at which point a new stable/pike branch will be created 14:03:44 and technically new patches can land 14:03:48 in master 14:04:13 also, I won't be online next week. I suggest we cancel the next week. 14:04:22 comments on that? 14:04:32 cool, caz i am taking PTO next week too 14:04:49 great. it makes us two, we'll cancel then. 14:04:50 +1 14:05:05 #topic Gate breakages 14:05:13 we had several of those the prev time we met 14:05:30 one was FlushError for ipallocations 14:05:34 that one was merged as https://review.openstack.org/#/c/485328/ 14:05:54 we also had https://bugs.launchpad.net/neutron/+bug/1704000 14:05:54 Launchpad bug 1704000 in neutron "Sometimes OVO unit tests clash on non-unique attributes" [High,Fix released] - Assigned to Lujin Luo (luo-lujin) 14:06:02 I *think* this is done now 14:06:22 yes, it is. 14:06:24 there were several patches, but I see one merged now and one abandoned 14:06:29 ok good 14:07:10 #topic OVO patches 14:07:30 https://review.openstack.org/#/q/status:open+project:openstack/neutron+branch:master+topic:bp/adopt-oslo-versioned-objects-for-db 14:07:49 since we can't merge anything of that till 2weeks+ from time.now()... 14:08:17 I think it makes sense to look at those where we are stuck 14:08:33 f.e. I wonder what's the state of https://review.openstack.org/466237 14:08:45 (adding relationship between router port and router) 14:09:04 I think there are some tracebacks in test run that are incriminating for the patch :) 14:09:13 i tried to look into the traces you mentioned in the comment, but i could not dig up anything 14:09:13 ihrachys, none of that can be merged till 2 weeks ? 14:09:19 lujinluo, have you had a chance to have a look at those? 14:09:46 manjeets_, yeah, we are in freeze mode for master right now, now blueprint work should merge unless it got an exception thru a formal procedure 14:09:57 now -> no 14:10:13 ohk 14:10:39 ihrachys: yeah, i checked that those traces are caused by the patch, but i cannot tell which part is causing that from the traces.. 14:12:59 lujinluo, yeah, it doesn't seem clear. maybe asking someone with better background on sqlalchemy session management could help 14:13:01 like Kevin 14:13:25 i see. i will reach out to him next next week.. 14:13:29 he has some experience with relationship definitions for subquery load 14:13:34 ok 14:14:52 manjeets_, I see you made progress for https://review.openstack.org/#/c/370452/ 14:15:06 I remember you had some issues with tests in the past. that's fixed in latest ps? 14:15:37 yup the object was just initialized not actually created in functional tests that causing some db errors 14:15:50 there were some issues with unit tests too but now fixed 14:16:27 i modified a a unit test little bit to add creation of actual object 14:16:47 great 14:17:28 is there any other patch of those that needs a check? 14:18:21 the floating ip patch. it turns out more db access is left in l3_db.py 14:18:43 https://review.openstack.org/#/c/396351/ i will add them up after i come back to work 14:19:17 so maybe we can save the review until then 14:19:27 ok, no rush. we are looking at 2weeks+ anyway. 14:20:00 or maybe even more, we will need to ask Kevin for a go signal. prev PTL was quite conservative to allow new stuff during RC phase even after branch created. 14:20:41 sure.. 14:21:01 #topic Open discussion 14:21:32 ihrachys, not related to this meeting but I have one general question 14:21:38 manjeets_, shoot 14:22:02 what library can be used to programmatically post comment on patches ? 14:22:20 also getting previous comments over the gerrit patch 14:22:37 well I haven't done THAT actually 14:22:47 a simple gerrit + python google search suggested https://pypi.python.org/pypi/pygerrit/0.2.1 14:23:03 I was able to fetch patches using pygerrit but not able to get api for getting comments 14:23:34 I think you may look at what infra does to post back from zuul 14:23:56 thanks !! thats a good idea 14:24:44 just drop at #openstack-infra and ask, they are usually helpful :) 14:25:13 ok, one more thing I'd like to mention is that I am going to propose a patch removing linuxbridge multinode grenade job from neutron gate 14:25:35 we left it for a whole cycle under premise that someone will pick it up and fix 14:25:58 Kevin even had a lead to the failure cause in https://bugs.launchpad.net/neutron/+bug/1683256 14:25:58 Launchpad bug 1683256 in neutron "linuxbridge multinode depending on multicast support of provider" [High,Confirmed] - Assigned to omkar_telee (omkar-telee) 14:26:06 but it seems it takes too long to execute 14:26:09 is it just removing from project config ? 14:26:36 what else do you think about? 14:26:50 I just can think of that atm 14:27:15 I can take it if its just that 14:27:59 manjeets_, ok, please do :) 14:28:09 #action manjeets_ to remove linuxbridge multinode grenade job from neutron gate 14:28:27 ++ 14:28:48 another thing I will mention is there is currently an upgrade bug that was triggered by neutron and affects ironic gate: https://bugs.launchpad.net/neutron/+bug/1705351 14:28:48 Launchpad bug 1705351 in neutron "agent notifier getting amqp NotFound exceptions propagated up to it" [High,In progress] - Assigned to Kevin Benton (kevinbenton) 14:30:10 the bug goes like - in new version neutron agents no longer listen to a fanout topic, but server still sends updates on it; the topic expires because of no consumers in the middle of a API request sending a fanout, it gets NotFound from AMQP broker, and it also results in oslo.messaging rabbitmq driver completely nuts because of missing cleanup of connection channel. 14:30:30 a rather twisted scenario, but basically it sometimes results in API requests timing out on tempest side 14:30:46 there is oslo.msg fix here: https://review.openstack.org/#/c/486706/ 14:31:24 and Kevin was also going to propose a patch that would mitigate the issue on neutron side (restoring bogus consumers on agent side that would just receive messages and drop) 14:31:37 so stay tuned if interested in the topic 14:31:46 anything else anyone would like to discuss? 14:32:00 none from me 14:32:05 none from me 14:32:26 ok, thanks for joining 14:32:30 we'll meet i 2weeks+ 14:32:31 thanks 14:32:33 #endmeeting