15:00:09 #startmeeting oslo 15:00:09 Meeting started Mon Mar 4 15:00:09 2019 UTC and is due to finish in 60 minutes. The chair is bnemec. Information about MeetBot at http://wiki.debian.org/MeetBot. 15:00:10 Useful Commands: #action #agreed #help #info #idea #link #topic #startvote. 15:00:12 The meeting name has been set to 'oslo' 15:00:27 o/ 15:00:29 courtesy ping for amotoki, amrith, ansmith, bnemec, dansmith, dhellmann, dims 15:00:29 courtesy ping for dougwig, e0ne, electrocucaracha, flaper87, garyk, gcb, haypo 15:00:29 courtesy ping for hberaud, jd__, johnsom, jungleboyj, kgiusti, kragniz, lhx_ 15:00:29 courtesy ping for moguimar, njohnston, raildo, redrobot, sileht, sreshetnyak, stephenfin 15:00:30 courtesy ping for stevemar, therve, thinrichs, toabctl, zhiyan, zxy, zzzeek 15:00:37 o/ 15:00:38 #link https://wiki.openstack.org/wiki/Meetings/Oslo#Agenda_for_Next_Meeting 15:00:39 o/ 15:00:57 o/ 15:01:01 o/ 15:02:52 #topic Red flags for/from liaisons 15:03:41 \o 15:03:47 I think the big thing on our side was that we merged a fix for oslo.cache + py3 + eventlet. 15:03:49 nothing new from Neutron that I am aware of 15:04:30 I was able to get that released before non-client library freeze too (sort of), so that type of environment should work in Stein now. 15:05:22 Otherwise things should be pretty quiet since we're in feature freeze now. 15:05:33 o/ Kind of here. 15:06:22 jungleboyj: It's Monday morning. "Kind of here" is about the best anyone can expect. ;-) 15:06:30 #topic Releases 15:06:34 :-) 15:06:40 There were a lot of them last week. 15:07:00 I released basically everything that had any pending changes, even if they don't normally require releasing (docs, test changes, etc.) 15:07:30 The reason being that a bunch of our stable branches got broken last cycle because they didn't get some necessary test fixes when we branched. 15:07:41 And that was because they were never released. 15:07:53 Also, we want the stable branch docs to be correct. 15:08:22 Be aware that we are now in non-client library freeze, which includes basically all of Oslo. 15:08:33 o/ (sorry - late due to snow-pocalypse) 15:08:45 So if there's anything we need to merge, it will require an exception from the requirements team. 15:09:16 Check out smcginnis's last release email for details. 15:09:26 Or just ping me if there's something you think needs to be released. 15:09:52 Otherwise that's probably it for releases this cycle. 15:10:03 Nice work, everyone! 15:10:30 #topic Action items from last meeting 15:10:40 "bnemec to look at hberaud's oslo.cache fix" 15:10:59 https://review.openstack.org/634457 15:11:01 I assume that was the pymemcache one, which I did look at. 15:11:24 So this was done. 15:11:30 yep 15:11:41 I want to discuss it a bit more later, but there's a separate topic on the agenda for that. 15:11:49 "kgiusti and gsantomaggio to investigate OSA rabbitmq_policies" 15:11:59 Any update on this one? 15:12:17 bnemec: there's a patch outstanding (checking status...) 15:13:15 bnemec: merged https://review.openstack.org/#/c/639299/ 15:13:18 If a patch was proposed then I'm calling it done. :-) 15:13:23 Even better! 15:13:34 "kgiusti document singleton pattern" 15:13:39 You're up again. :-) 15:13:43 did it! 15:14:29 bnemec: not done - is this something we can do now that the freeze is in place? 15:15:44 kgiusti: If it's just a doc change we can merge it, but it won't make the Stein docs unless we either have to release oslo.messaging again for a critical fix or we backport it after branching. 15:15:55 kgiusti: Is https://review.openstack.org/#/c/639152/ related to this? 15:16:21 bnemec: no - that's Something Completely Different 15:16:53 bnemec: I never understood why rabbit driver opens a new connection for each listener - restored an old comment to the code that explains why 15:17:04 Okay, thanks. 15:17:06 wait 15:17:10 this is not RAbbitMQ 15:17:16 this is Py-AMQP 15:17:33 or oslo-messagging ( I don't know yet ) 15:17:53 gsantomaggio: yes - I mean the rabbit _driver_ - that's oslo.messaging and it's the code that actually opens the extra conns 15:18:06 gsantomaggio: something we can fix :) 15:18:19 one of the problem is about the connection 15:18:31 in py-amqp is not thread-safe 15:19:20 so the easier way is to open one connection per thread 15:20:05 gsantomaggio: yup. that's how the other drivers are designed: one thread dedicated to a URL (socket) 15:20:12 and also another problem is about the basic_ack ( normally should be thread-safe) but in py-amqp is not thread-safe 15:21:22 @kgiusti go it 15:21:26 @kgiusti got it 15:21:42 gsantomaggio: feast your eyes upon this: https://bugs.launchpad.net/oslo.messaging/+bug/1776492 :) 15:21:43 Launchpad bug 1776492 in oslo.messaging "can oslo_messaging support basic.return " [Wishlist,Confirmed] 15:21:53 Okay, so there's more to be done here. 15:22:02 gsantomaggio: nearly a year old :( 15:22:28 As long as it's on someone's todo list that's good enough for the meeting. :-) 15:22:43 We can certainly follow up on this though. 15:22:50 "moguimar to follow up on status of py35 in the gate" 15:22:55 This was done. 15:23:16 o/ 15:23:20 Let me find a link because it's worth taking a look at. 15:23:56 #link http://lists.openstack.org/pipermail/openstack-discuss/2019-February/003202.html 15:24:16 This is actually going to come up in a later topic too, so we'll move on. 15:24:22 That was it for action items from last week. 15:24:34 #topic Oslo Forum Sessions 15:24:59 I didn't start an etherpad for this because I don't know that we need to have any Oslo-dedicated forum sessions. 15:25:14 I did propose an oslo.limit topic on the Keystone etherpad though. 15:25:41 If you do have something that you think would benefit from discussion at the Forum, please let me know ASAP though. 15:25:52 the Castellan guys are planing to do something I think 15:26:06 redrobot ^ 15:26:25 Cool. 15:26:28 \o 15:27:08 Yeah, There were a few topics in Castellan that need discussion. Not sure if Forum or PTG would be best though? 15:27:46 Yeah, I'll start a new PTG etherpad sometime in the near future. 15:27:59 Maybe I should just go ahead and do that now and we can figure it out from there. 15:28:15 It'll be easier to have the discussion if we have the topics for discussion written down ahead of time 15:28:32 #action bnemec to start PTG/Forum topic etherpad 15:29:28 #topic Bionic Migration 15:29:37 #link http://lists.openstack.org/pipermail/openstack-discuss/2019-February/003129.html 15:30:19 We have about a month before all of the legacy jobs switch over to bionic. 15:30:39 I'm not actually sure if we have much in the way of legacy jobs in Oslo at this point. 15:31:08 Most of our repos are using exclusively templates from the central job repo, and I assume those are all v3-native now. 15:31:39 So it may be that we don't actually have much to do on this. 15:32:06 When I added it to the agenda I was thinking we'd need to push test patches for basically every Oslo repo, but it may be more of an investigation thing instead. 15:32:29 Just verify that our repos aren't using legacy jobs, and only push test patches for the ones that are. 15:32:39 Which may be none. 15:33:14 If anyone wants to dig into zuul configs, be my guest. :-) 15:33:26 Otherwise I'll try to poke at this sometime this week. 15:34:04 Oh, and on a bionic-related note: 15:34:21 I would prefer to hold off on the py35 job removal until after the migration is complete. 15:34:42 The reason being that until that happens, some projects will still be running Oslo code in the gate under py35. 15:35:03 While the unit test jobs don't provide perfect coverage, it's better than nothing and it doesn't cost a lot of resources. 15:36:06 So the main thing is not to merge py35-removal patches until after April 1st. 15:36:25 I'm even going to action that one to highlight it for anyone reading the meeting minutes. 15:36:57 #action Oslo cores to hold py35 removal patches until after Bionic legacy job migration on April 1 15:37:07 No, this is not an April Fool's Day joke. ;-) 15:37:28 #topic pymemcache and oslo.cache 15:37:49 This is mostly for hberaud and kmalloc. 15:38:14 on my side I guess I'm done and I'm waiting kmalloc review 15:38:26 Given that there seems to be some more investigation needed on this in terms of how it works on upgrade, I think we should hold off on this until Train. 15:38:41 Especially since we're in feature freeze and this would add a new dependency. 15:39:10 bnemec: yeah right 15:39:19 Plus we have my awful hack of a "fix" to the existing code that should unblock people using this in Stein. 15:39:48 lol 15:39:58 hberaud: Okay, just wanted to make sure we were on the same page about this. 15:40:21 yeah it's ok 15:40:32 guys, gotta drop sonner, cya o/ 15:40:33 hberaud: I do want to get it in early next cycle so we have lots of time to validate it before the next release. 15:40:44 moguimar: Thanks for joining 15:41:20 sure 15:43:32 #topic Weekly Wayward Review 15:43:38 #link https://review.openstack.org/#/c/610578 15:43:45 I just approved it. :-) 15:44:07 We're pretty limited in what we can merge right now anyway, so we may skip this part of the meeting in future weeks. 15:44:20 A py37 job addition should be okay though. 15:44:30 #topic Open discussion 15:44:35 Anything else this week? 15:44:50 Can some can add this to todo list => https://review.openstack.org/639661 ? 15:46:18 s/some/someone/ 15:47:57 hberaud: How critical is this? I'm not sure we could release it right now even if that merged. 15:48:17 pbr is an independent release project, but we generally still freeze them during feature freeze so we don't accidentally break the world. 15:48:33 Particularly for something like pbr that is used...everywhere. 15:48:48 bnemec: ack 15:50:09 Which is not to say that we can't review the change. It may just have to wait a few weeks until we branch. 15:50:55 I probably need to look closer at the difference between a csv and multi field. 15:51:17 Merged openstack/oslo.cache master: add python 3.7 unit test job https://review.openstack.org/637699 15:51:59 bnemec: ack 15:52:49 Okay, anything else? 15:55:14 Thanks for joining everyone! 15:55:16 #endmeeting