15:00:59 #startmeeting kolla 15:00:59 Meeting started Wed Jul 28 15:00:59 2021 UTC and is due to finish in 60 minutes. The chair is mgoddard. Information about MeetBot at http://wiki.debian.org/MeetBot. 15:00:59 Useful Commands: #action #agreed #help #info #idea #link #topic #startvote. 15:00:59 The meeting name has been set to 'kolla' 15:01:07 #topic rollcall 15:01:25 \o 15:01:43 o/ 15:02:27 -o 15:02:56 _[o][o]_ 15:04:49 mgoddard mnasiadka hrw egonzalez yoctozepto rafaelweingartne cosmicsound osmanlicilegi bbezak parallax Fl1nt 15:04:52 ^ meeting time 15:05:48 o/ 15:07:23 #topic agenda 15:07:30 * Roll-call 15:07:32 * Agenda 15:07:34 * Announcements 15:07:36 * Review action items from the last meeting 15:07:38 * CI status 15:07:40 * Release tasks 15:07:42 * Xena cycle planning 15:07:44 ** Xena feature prioritisation https://docs.google.com/spreadsheets/d/1BuVMwP8eLnOVJDX8f3Nb6hCrNcNpRQl57T2ENU9Xao8/edit?usp=sharing 15:07:45 o/ 15:07:46 * Kolla operator pain points https://etherpad.opendev.org/p/pain-point-elimination 15:07:48 * Open discussion 15:07:50 #topic announcements 15:07:52 None from me 15:07:54 Anyone else? 15:08:39 #topic Review action items from the last meeting 15:09:03 None, but I have proposed some stable releases which was a recent action 15:09:11 #topic CI status 15:09:16 #link https://etherpad.opendev.org/p/KollaWhiteBoard 15:09:40 I've seen a few networking issues recently 15:09:47 I think intermittent 15:10:23 Are there any other issues? 15:10:37 Grafana is still causing issues, probably depending on CI vendor 15:11:13 you mean on infra mirrors? 15:11:17 Some mirrors might still have the erroneous package metadata cached while others don't 15:11:30 could be 15:11:33 yoctozepto: yeah - I'm wasn't sure whom to talk to about it 15:11:35 it could also be CDN issue 15:11:43 #opendev 15:11:51 upstream problem is already resolved 15:12:20 iirc there is no cache for grafana 15:12:23 yeah, but I mean often it is that some upstream CDN is flaky and some mirrors rely on it (as some mirrors are just caching proxies) 15:12:25 or is it? 15:12:38 have not checked, relying on parallax here 15:13:14 I'm just saying building it works on my machine :) In CI - intermittent 15:14:37 #topic Release tasks 15:15:29 I don't think we have anything this week 15:15:56 #link https://docs.openstack.org/kolla/latest/contributor/release-management.html 15:16:00 (yay, merged) 15:16:29 currently we are R-10 15:16:38 so binary xena in 2 weeks time 15:16:55 do we have any more TODOs/cleanup left? 15:17:17 no idea, I'm still lagging behind 15:17:24 does anyone want to check what we've done and what's left? 15:18:27 tough crowd 15:19:03 #topic Xena feature prioritisation 15:19:17 #link https://docs.google.com/spreadsheets/d/1BuVMwP8eLnOVJDX8f3Nb6hCrNcNpRQl57T2ENU9Xao8/edit?usp=sharing 15:19:52 I extracted patches from gerrit, and put them into a sheet 15:20:19 looking 15:20:20 I went through and assigned a Type to each 15:20:31 so now we can filter for features, bugfixes, etc 15:20:38 wow 15:21:15 for kayobe, we went through together and assigned some patches to Xena, and gave them a numeric priority 15:21:22 grat 15:21:35 then they can be ordered and put into the whiteboard for reviewers 15:21:40 it's missing one thing 15:21:48 the actual project 15:21:53 ? 15:22:01 see tabs at the bottom 15:22:03 ah, I see tabs 15:22:04 yeah 15:22:42 I'm not sure that a community-wide priority makes sense for kolla 15:23:02 but what we could do is allow people to register interest to 15:23:04 I think that we can identify quick/trivial changes and get them in to get list shorter 15:23:07 1. contribute 15:23:18 2. review 15:23:20 3. use 15:23:57 interesting approach 15:24:01 ultimately resulting in a system where contributors can get reviewers to sign up to review their code 15:24:32 now only need to support payments in bitcoin :-) 15:24:44 a big downside is that this is a snapshot, and not easily updated for new patches 15:25:18 but it only took a couple of hours, and it could be done manually from there to add new features to a list 15:26:19 I suppose the ultimate aim is to allow us to focus on reviewing important patches 15:26:29 rather than being gerrit email event driven 15:26:47 or small patch dopamine driven 15:27:14 if anyone has ideas of how to use this data to help, I'm listening 15:27:16 yeah, we are looking for oxytocin here 15:28:06 well, it could make sense to propose an overlay system on gerrit to better manage these efforts 15:28:20 this looks like the first (manual) PoC on that 15:28:21 Could you make the script you used to generte it smarter so that priorities, etc. were preserved on update? 15:28:39 mhm, that would be a good progress forward 15:28:48 we can wire something simple up with sqlite 15:29:14 or even just json-file-based database 15:29:26 that would be easiest 15:29:35 what is wrong with using RP+1/RP+2 for marking trivial/important patches? 15:29:53 haerwu: it doesn't really give enough info 15:29:56 how do we decide which are important? 15:30:05 precisely 15:30:08 ok 15:30:18 gerrit doesn't do a lot to help us here 15:30:30 Bugs have their priority 15:30:47 it would be cool to have this flow 15:31:16 change comes in -> gets assigned a type -> gets assigned the priority (or left for discussion on that) -> gets reviewed thoroughly 15:31:33 any solution that is itself feature sized would probably negate this work :) 15:31:40 we have hashtags in gerrit 15:31:47 only the author can set them 15:32:05 shit. 15:32:21 yeah 15:32:30 mayhaps that can be fixed? 15:33:19 I'll ask on opendev 15:33:21 I'm not convinced that managing that in a spreadsheet instead of using Gerrit custom labels/topics/commit message ,,metadata'' will help with anything, but I'm listening ;) 15:34:03 the problem is that gerrit does not provide a suitable value to configure 15:34:13 yoctozepto: thanks 15:34:14 Can't we do custom labels? 15:34:18 gerrit would be ideal, since it could be queried 15:34:19 hashtags would solve our problem 15:34:28 with custom views etc. 15:34:47 mnasiadka: labels are numeric; hell no, I don't want +2 for bugfix :-) 15:34:58 https://gerrit.wikimedia.org/r/c/All-Projects/+/416357/4/project.config suggests option for it 15:35:03 yoctozepto: you can set that +2 is CI, +1 is something else, and so on 15:35:11 17:34:58 yoctozepto: it can be. Zuul and Ironic have done this. I think we might consider allowing it across the server though? 15:35:16 YAY 15:35:42 well, we can just raise a change to allow it in kolla projects? 15:35:51 before it gets done across the server... 15:36:17 yoctozepto: cool ;) 15:36:27 mnasiadka: yeah, /me on it 15:36:29 sounds good 15:36:41 teamwork ftw :-) 15:36:47 still, I think it is the wrong part of the problem to focus on 15:37:03 ok, elaborate 15:37:07 I'm trying to fill the vacuum left by not having priorities 15:37:46 a limitation of those priorities was that many did not get implemented 15:38:05 well, we can manage tags in the spreadsheet instead 15:38:10 topics too 15:38:20 so I'm suggesting we look instead at what has been proposed already 15:38:29 or at least what someone has promised to propose 15:38:47 but the question then is how to we prioritise them 15:39:04 since we have many more patches being proposed than we can review 15:39:18 we need to make better use of our time, and focus on the 'right' patches 15:39:51 #cleanup #drop #trivial as things we want to get once and forget 15:40:15 17:39:18 we need to make better use of our time, and focus on the 'right' patches 15:40:18 I could not agree more 15:40:31 and perhaps create some feedback between contributors and available review bandwidth 15:41:03 how do we get from what we have today, to tidied and properly tagged patches? :) 15:41:24 Skylar Tristan Kelty proposed openstack/kolla-ansible master: Update Manila deploy steps for Wallaby https://review.opendev.org/c/openstack/kolla-ansible/+/802743 15:41:51 I might not have made it clear - the spreadsheet is just a tool. I expected (pre-hashtags) the outcome to be a YAML-ish list in the whiteboard 15:43:02 why not a Gerrit dashboard with categorized entries? 15:43:10 that would be nice 15:43:17 what categories would be useful? 15:43:46 #xena 15:44:03 #feature 15:44:05 #bugfix 15:44:08 cleanup, trivial, drop, new feature, ci fix, maintaince (with better word for is as I always forget how to write it)? 15:44:39 #to-backport 15:44:40 #priority-high, #priority-medium, #priority-low? 15:44:47 we would need a patch triage system to make this work 15:44:49 jovial`: that's handled by RP 15:44:56 true 15:45:10 haerwu: and backport by backport candidate 15:45:20 anyhow, https://review.opendev.org/c/openstack/project-config/+/802744 15:45:36 yoctozepto: "#to-backport #victoria #bugfix" 15:46:27 victoria is a branch, that gets into stable backports category in Gerrit dashboard and is easy to find without hashtags 15:46:30 If you let anyone edit the hashtags is there a danger of vandalism? 15:46:45 jovial`: I only allow cores 15:46:47 I think we should only let cores edit hashtags 15:47:13 mnasiadka: yup, my thoughts exactly 15:47:15 so, can somebody summarise what we can't set today? backports and priority is possible now 15:47:15 I have a fix for Victoria. So I send patch to master, add '#victoria #bugfix', set BC+2 and give bug# in commit 15:47:59 mnasiadka: kind, but that is easily solvable with standardised hashtags 15:48:06 which we will be able to modify now 15:48:09 once it in master, I backport to W and V with same hashtags 15:48:15 yoctozepto: agreed 15:48:22 and V gets BC-2 15:48:27 wonder if hashtags are copied on cherry pick ;) 15:48:37 can be added by core 15:48:39 haerwu: that makes sense to me 15:48:54 mnasiadka: yeah, need to check, I think they are 15:48:58 So let's define some basic ones we start with, and add additional ones on the way? 15:49:08 mnasiadka: +++ 15:49:09 before we go and add a bunch of extra admin to an already stretche team... 15:49:15 I can play with Gerrit dashboard 15:49:26 ... use cases 15:49:29 and document the official tags 15:49:38 yeah, in contributor guide 15:50:01 so the tags are... 15:50:05 if we start from the queries we think would actually be useful 15:50:12 we can work backwards to hashtags 15:50:30 but there is also the question of how to decide which hashtags to apply to a patch 15:50:48 mhm 15:50:56 if the main goal is to tag important patches to focus on, how do we decide which are important? 15:51:16 those related to ,,priority features'' we want to implement in the cycle? 15:51:26 I think that we will go with tagging patches as we review them too 15:51:27 and those that unbreak CI, as always - for a starter 15:51:29 and how do we decide what those are? 15:51:56 mgoddard: that's very interesting question :) 15:52:06 I suppose if we had a #feature tag it would be easier to find features 15:52:21 yes, feature is a must 15:52:23 and easier to rank them 15:52:26 we can also have a specialised one 15:52:26 yes, but it's also easy to find them today if they have bp/something in topic 15:52:33 for features being our priorities 15:52:37 just that :-) 15:52:47 #priority-feature ? :) 15:52:55 how about this 15:52:56 yeah, something like that 15:52:58 or just #feature with RP+2 15:53:14 a feature is a priority for a release if two cores agree to review it 15:53:33 hmm 15:53:43 this is one of the problems I'd like to solve 15:53:46 and then we need a system to collect who agrees to overview the work 15:53:56 yes 15:54:10 I think it's not too hard 15:54:20 we document the proces 15:54:23 cores as hashtags anyone? 15:54:25 #yoctozepto 15:54:40 patch author or interested party drives the process to become prioritised 15:54:57 * yoctozepto worried about getting overtagged 15:55:21 we agree as a team at meetings that criteria are met, and add the tag 15:55:40 mgoddard: I mean change owners can set tags freely 15:56:05 we need a system of punishments then 15:56:13 1 month of no core reviews for abuses 15:56:17 it's not the end of the world if it gets abused 15:56:29 someone might review a patch 15:56:44 yeah, I'm just laughing here 15:56:53 I think it really is sensible 15:57:21 of course, a future PTL may throw it out 15:57:57 I think mnasiadka likes what we design 15:58:22 there's some nice feedback involved 15:58:30 contributor proposes patch 15:58:35 nobody signs up to review 15:58:42 hmm, maybe I need some karma 15:58:47 they do some reviews 15:58:59 2 cores sign up 15:59:03 patch lands 15:59:04 well, contributors joining our meetings would be cool as well 15:59:08 sure 15:59:43 oh my, we ate up the whole meeting 15:59:54 but also it may help reviewers focus on patches they signed up for, and not keep contributors hanging 15:59:57 how did THAT happen 16:00:06 there is one more topic 16:00:17 #topic Kolla operator pain points 16:00:21 #link https://etherpad.opendev.org/p/pain-point-elimination 16:00:45 This is being mooted as a potential Y cycle priority 16:00:59 Operator pain points 16:01:07 we would need to decide on 1-2 16:01:28 if anyone has suggestions, please add them to the linked etherpad 16:01:38 need to ask less-internal operators I guess? 16:01:42 we can review next week 16:01:50 ++ 16:02:03 sure, I could resurrect the kolla-klub mailing list 16:02:13 +++ 16:02:24 we shouldn't be writing what are operators pain points :) 16:02:27 #action mgoddard email kolla-klubbers & openstack-discuss about pain points 16:02:35 mnasiadka: you're not an operator? 16:02:52 but yes, I see your point 16:03:00 I think mnasiadka has a similar stance to mine; we understand the internals and can adapt easily 16:03:06 mgoddard: I'm a special type of an operator, that pushes a patch 15 minutes after finding a pain point :) 16:03:15 :-) 16:03:18 if only they were all like mnasiadka 16:03:27 anyway, time's up 16:03:33 thanks all 16:03:36 thanks mgoddard 16:03:36 ideal world doesn't exist and we wol 16:03:38 #endmeeting