15:00:18 #startmeeting tc 15:00:18 Meeting started Thu May 19 15:00:18 2022 UTC and is due to finish in 60 minutes. The chair is gmann. Information about MeetBot at http://wiki.debian.org/MeetBot. 15:00:18 Useful Commands: #action #agreed #help #info #idea #link #topic #startvote. 15:00:18 The meeting name has been set to 'tc' 15:00:22 #topic Roll call 15:00:26 o/ 15:00:27 o/ 15:00:37 o/ 15:00:42 o/ 15:00:51 * slaweq is on time :) 15:01:34 o/ 15:01:50 o/ 15:01:51 o/ 15:02:16 let's start 15:02:19 #link https://wiki.openstack.org/wiki/Meetings/TechnicalCommittee#Next_Meeting 15:02:22 ^^ today agenda 15:02:32 #topic Follow up on past action items 15:02:52 none from previous meeting 15:03:02 #topic Gate health check 15:03:06 any news 15:03:19 so there was something mentioned about my dbcounter thing breaking jammy, 15:03:27 but for reasons that make no sense and I haven't been able to repro locally 15:03:44 ok, jammy jobs are made non voting now 15:03:45 like, pip complaints that the python-builtin module 'glob' is not available <-- makes no sense 15:03:48 right 15:04:01 humm 15:04:15 other than that, 15:04:25 I've got this proposed: https://review.opendev.org/c/openstack/devstack/+/838947 15:04:38 which attempts to highlight perf regressions, although I think it's still up in the air whether or not it's worthwhile 15:04:44 but might be interesting to some 15:05:15 +1, this will be helpful 15:05:22 I will review it 15:05:26 also sounds like a couple people are working gate stability fixes through, for instance resize and one other I forget at the moment 15:05:43 yeah, c9s again failing on detach volume things, which again is going to be fixed/workaround by making test SSH-able 15:05:49 dns resolver startup race for fips jobs 15:05:59 oh there's some tripleo c9s failure too I think 15:06:15 related to libvirt and libvirt-python being broken in cs9 right? 15:06:17 I am trying to make all detach volume waiting for SSH-able server but not yet passing #link https://review.opendev.org/c/openstack/tempest/+/842240 15:06:23 yeah 15:06:37 at this point we're thinking we should probably change the systemd service unit for unbound so that the system doesn't consider itself fully "booted" until dns resolution works 15:07:13 #link http://lists.openstack.org/pipermail/openstack-discuss/2022-May/028568.html 15:07:47 fungi: ok 15:08:08 o/ 15:08:16 not sure if ubuntu image with fips are available or when to be available. I am less hope of having c9s stable for this testing 15:08:27 o/ 15:08:54 I think ade_lee will be keeping eyes on it 15:09:03 anything else on gate? 15:09:17 not from me 15:09:23 I definitely will 15:09:29 I still didn't had time to make script to count "naked" rechecks in projects 15:09:33 gmann: ade_lee prodded the canonical folks about ubuntu fips options again this week, no response yet that i've seen 15:09:34 ade_lee: thanks 15:09:39 but I hope I will have more time for it next week 15:09:55 so hopefully I will have some data on next meeting 15:09:57 slaweq: np!, thanks for working on it. 15:10:16 fungi: I see. thanks for updates 15:10:28 #topic Zed cycle tracker checks 15:10:31 #link https://etherpad.opendev.org/p/tc-zed-tracker 15:10:41 we have many item in progress and under review 15:11:16 but please start the items not yet started. 15:11:31 any updates or anything on zed tracker today ? 15:11:49 I talked to Artem and Belmiro for the OSC. 15:12:01 To get an idea where things are. 15:12:12 Artem is (ofc) very interested. 15:12:23 yeah 15:12:45 He mentioned Glance and Cinder (IIRC) as areas which need improvement. 15:12:58 To which I replied we have dansmith :-D 15:13:01 I think that this https://review.opendev.org/c/openstack/governance/+/840856 is ready for review 15:13:04 :) 15:13:12 :-) 15:13:14 so if You have time, please take a look 15:13:18 Artem has a fourm session on this at the summit. 15:13:20 slaweq: ack 15:13:26 *forum 15:13:45 I guess this will provide a good starting point what issues to tackle for the OSC. 15:13:49 arne_wiebalck: do you think this is ready for making goal now or pop-up team to get progress for glance, cinder? 15:14:23 gmann: how about we wait for the forum session to answer your question? 15:14:36 arne_wiebalck: ok, sounds good plan 15:14:46 arne_wiebalck: I'm very pro-glance-being-better-on-osc, but I am in the vast minority :) 15:15:31 humm 15:15:33 let 15:15:33 cinder is supposed to meet with some OSC people either next week or during our first midcycle to discuss 15:15:40 +1 15:15:49 dansmith: would be good if the glance folks came to the forum session maybe? 15:15:55 rosmaita: great 15:16:05 let's see how it goes in forum and I think having it as a goal can push work more fast 15:16:14 there are some big issues around how the OSC syntax does not make sense for some operations 15:16:18 gmann: ++ 15:16:32 and to what extent that can be addressed 15:17:01 ok 15:17:06 anything else on this? 15:17:15 not from me 15:17:20 arne_wiebalck: thanks for checking and start working on it. 15:17:42 #topic TC meeting with Board of Directors 15:18:07 one update on this. we have 45 min time to meet/present to board. 15:18:32 I will prepare the slides as per the agenda discussed and share with you all for review/updates 15:18:35 \o/ 15:18:49 thanks gmann :) 15:18:58 Glad that we could reach an agreement on that. Thank you gmann! 15:19:09 has that meeting been scheduled yet? and who is encouraged to attend? 15:19:50 it is in draft agenda but details will be soon on how to join and who all can join. non board member need RSVP I think 15:19:55 btw who all are planning to be in-person in summit 15:20:02 not me 15:20:04 I am planning to join virtually 15:20:21 I will be in Berlin 15:20:22 not me 15:20:29 oh, wait, this is during the board meeting in berlin? i thought the project leaders weren't meeting with the board there 15:20:30 I will not be physically or virtually. I will be on a lake with little to no wifi. 15:20:42 but I didn't plan to go to the Board meeting on Monday 15:20:50 and TheJulia was scheduling alternative meeting options for project leadership 15:20:52 fungi: yeah TC+Board. 15:21:24 I will be in Berlin as well. 15:21:38 fungi: there was much confusion, but I think the end result was a short meeting with the board during the board meeting, and then longer virtual openstack-specific call later 15:21:39 fungi: you mean project+board interaction? that is separate topic I have proposed 15:22:20 oh, thanks. so two separate meetings. openstack gets 45 minutes during the board meeting, and then there will be a separate openstack+board meeting as well 15:22:22 dansmith: That was my understanding as well. 15:22:52 fungi: Yes and I think that the separate meeting will be one or more virtual meetings 15:22:58 i will be in Berlin and on monday as well 15:23:18 but other projects will not have an opportunity to meet with the board in berlin, only openstack? 15:23:19 fungi: no, 45 min OpenStack+Board. other one is in board formal meeting on topic "Open Infra project+board interaction" 15:23:23 I'll be in Berlin 15:23:34 fungi: TheJulia is talking to other projects 15:23:54 so arne_wiebalck slaweq spotz knikolla will be there 15:24:10 yeah, i've been in those conversations. just making sure i understand that teh other projects aren't being handled the same as openstack this time 15:24:16 gmann should I then plan to be on the meeting with Board on Monday? 15:24:29 let board schedule comes out. it is still in draft for other projects or so 15:24:30 fungi: I don't think there's any special treatment going on here 15:24:41 i think it wasn't clearly communicated to other projects that only openstack leadership would be participating in the board meeting 15:24:52 fungi: yeah. its same for everyone. 15:24:56 fungi: there was definitely confusion about the different plan this time and the other projects hadn't (last I heard) expressed a need/desire 15:25:27 I will be travelling on Monday (the TC/board meeting arrangements were made somewhat late relative to travel organisation so I did not take this into account) 15:25:31 yes, few have not responded yet may be. but TheJulia is asking to all proejcts 15:25:42 arne_wiebalck: ack 15:25:55 gmann: at which time is the meeting? 15:26:01 * arne_wiebalck could probably look this up ... 15:26:04 anyways let baord schedule comes out and how other projects are planning 15:26:17 the communications i was in on indicated that the board of directors didn't have time to meet with project leadership in berlin and were interested in setting up separate meetings 15:26:34 arne_wiebalck: 9am -5 pm local time but with two part 15:26:49 anything else on this topic? 15:26:51 so openstack being involved in the board meeting is definitely not consistent with what was communicated, hence my confusion 15:27:06 fungi: there was much confusion 15:27:13 gmann: thanks! 15:27:20 fungi: yeah those were all confusion but we are checking with all projetcs 15:27:41 thanks for confirming. i'll try to follow up with TheJulia to get a clearer explanation 15:27:54 #topic New ELK service dashboard: e-r service 15:27:59 dpawlik: any updates on this? 15:28:29 I'm not sure if dpawlik is still there 15:28:40 but he told me that he didn't make anything new 15:28:51 ok. thanks for updates 15:28:54 and that dasm is working on e-r 15:29:06 cool 15:29:09 but I don't have more details about it 15:29:17 #topic 'SLURP' as release cadence terminology 15:29:43 so SLURP is agreed name and I have proposed patch to change name in resolution #link #link 15:29:53 #link https://review.opendev.org/c/openstack/governance/+/840354 15:29:56 please review that 15:30:14 release notes part as discussed will be handled by rosmaita 15:30:31 i will have a patch up about that ... soon 15:30:36 cool, thanks 15:30:42 anything else on this? 15:31:24 #topic Use release number or name in development process/cycle 15:31:29 elodilles: ttx ping 15:31:40 o/ 15:31:59 we agreed to handover the release name process to Foundation and TC will not be involved in that 15:32:10 so no question on this part 15:32:29 ++ 15:32:44 but while proposing it documentation, another part came up how to use name/number in developement cycle 15:33:04 like release page, schedule, automated tooling etc 15:33:15 branch names 15:33:17 I have proposed 3 option for this #link https://review.opendev.org/c/openstack/governance/+/841800/2/reference/release-naming.rst#36 15:33:23 yeah, branch name 15:33:34 and release team also discussed it in their meeting 15:33:35 in rel-mgmt weekly meetings the milestone name and branch name came up 15:34:33 release page title can be both "OpenStack 2023.1 AA" 15:34:47 ++ 15:34:48 but milestone and especially branch name should be number? 15:35:13 we discussed that milestone name is more clear with name 15:35:18 and so other automated tooling, dir structure in spec repo etc 15:35:33 e.g. aardvark-1 compared to 2023.1-1 milestone 15:35:46 My thought was use name only in marketing side 15:35:56 the primary concern being that 2023.1-1 might make consumers think 2023.1 is already released 15:36:02 and in developement process during or at the release we use number 15:36:17 no, i think the idea was that the community likes using the names 15:36:23 maybe something like 2023.1-m1 15:36:38 +1, 2023.1-m1 is more clear 15:37:20 rosmaita: that is my concern, if we continue using name in everywhere then how number will be communicated, they will be just go un-notice 15:37:20 i thought the problem we were trying to solve was that while names are fun, it was no longer fun to try to come up with names 15:38:17 well, right now the version numbers are more confusing that useful, so switching to the new format and promoting them to more wide use would be good IMHO 15:38:32 especially in preparation for the foundation throwing up their hands in two years and saying "meh names are too hard" :P 15:38:48 dansmith: :-D 15:38:52 yeah, promoting numbers has long term benefits 15:38:53 i thought we were keeping the confusing individual project version numbering? 15:38:57 :-) 15:39:12 rosmaita: isn't that the whole point of the unified date versioning? 15:39:15 rosmaita: yes, they stay same 15:39:20 so get everyone on the same thing? 15:39:21 oh? 15:39:23 dansmith: see^^ 15:39:25 then I'm very confused 15:39:34 no change in number schema what belmiro proposed and we all agreed 15:39:41 belmiro's original update specifically said ^^ 15:39:46 okay I totes missed that 15:40:16 my impression was that the point was we will have Austin and Aardvark and need to know which is first 15:40:23 #link https://governance.openstack.org/tc/reference/release-naming.html#release-identification 15:40:26 so we will have 2023.1 Aardvark 15:40:46 rosmaita: yeah that is there till we were ok with name also 15:41:15 right, and i thought we were revising because we couldn't come up with a good naming process 15:41:18 as name are moving towards the marketing usage we should just use the number and name where we need more market things 15:41:20 but that problem is now solved 15:41:44 i think we continue to use both as long as we have them both 15:41:58 rosmaita: so even with '2023.1 Aardvark' what is your idea on branch, release miletsone, spec dir side? 15:41:59 where on there does it say the project versions stay the same? 15:42:32 we cannot use both there, it should be one right? 15:42:34 not there it's in the resolution 15:42:42 okay 15:42:57 sounds like release team prefers name for milestone 15:43:02 stable/2023.1 or stable/AA or stable/2023.1.AA ? 15:43:11 rosmaita: ++ 15:43:11 and we already have the branch tooling set up around names 15:43:28 rosmaita: ++ :) 15:43:36 and we'll never have two of the same beginning letter in the stable branches 15:43:38 that is what changes are proposed and we need to change tooling also 15:43:42 because we delete eol branches 15:44:15 so I will ask differently - do we really need that version numbers? If we are going to use name everywhere like it is currently 15:44:19 so just drop the number things as we are not using them anywhere than just in TC release-naming-process-page 15:44:34 slaweq: exactly 15:44:43 they will probably be used elsewhere 15:44:54 if we are not changing the implementation then there is no use of number 15:44:56 I feel like we have just gone in a circle. 15:45:00 elsewhere where? 15:45:07 jungleboyj++ 15:45:19 like announcements, "openstack releases 2023.1 Aardvark" 15:45:41 i missed where the tooling discussion happened, i guess 15:45:48 but at least name will not be choosen by TC anymore, and that's basically only change I think 15:46:01 slaweq: that was my understanding 15:46:02 I think our main purpose for number is to give operator, user start knowing openstack release by number 15:46:16 which IMHO is also good if that's what is prefered 15:46:19 rosmaita: you mean use name everywhere and number only in marketing ? 15:46:28 i thought it was for assisting them 15:46:39 rosmaita: release tooling was discussed in the release meeting last friday 15:47:04 #link https://meetings.opendev.org/meetings/releaseteam/2022/releaseteam.2022-05-13-14.00.log.html#l-41 15:47:57 yeah, but i am on the tc not the release team 15:48:11 I think we need to first decide or re-decide that we want OpenStack release to be primarily identified by NAME or NUMBER ? 15:48:26 Name:) 15:48:50 rosmaita: we have not discussed in TC and just said Number as primary identifier 15:49:03 spotz: then why we agreed on number in release process? 15:49:11 release name process 15:49:13 rosmaita: the release managers manage the release tooling/automation, so release tooling changes get discussed in the release meeting 15:50:06 and then raised with the tc in the tc meeting 15:50:07 this section explain why we need NUMBER #link https://governance.openstack.org/tc/reference/release-naming.html#release-identification 15:50:50 gmann I've been arguing for name all along. And there's 2 ways to think of the primary identifier, what everyone calls it and what's in the systems 15:50:51 IMO, if we are keeping name as it is then we just remove the Number things as it will be un-used and un-notice 15:51:32 spotz: you +1 on release number things #link https://review.opendev.org/c/openstack/governance/+/829563 15:51:45 to be honest, the addition of the number if we're not moving projects to that seems like we've just added another disjoint version number.. it was mentioned in the commit and in the comments on the last PS, 15:51:55 but it really (really) wasn't what I was thinking we were doing 15:51:59 But, in the page you reference above it says that we need the number as it being the 'A' release is ambiguous given that we are on our second iteration through the alphabet. 15:52:08 I think that even if we will be using both, like e.g. AArdvark 2023.1 then everyone will in practice use only Aardvark 15:52:15 OK, so where that page says "The release identification schema doesn’t replace the release name. It’s just an unambiguous way to identify OpenStack releases.", what has changed? 15:52:24 If that's the direction we were going I supported it, but that patch is WAY behind our more recent discussions 15:53:08 mentioned in the commit *message* I should say, 15:53:12 but not on the actual doc we were reviewing 15:53:28 I don't have a problem with adding the 2023.1 designation. I see its usefulness. 15:53:59 jungleboyj: totally agree 15:55:01 so we are moving back to ground because it is hard/not-prefered to use number in release miletsone and stable branch? 15:55:31 if keeping the name anywhere is going to prevent people from fully switching to numbers, that tells a bit about how much humans prefer to communicate using words :) 15:55:39 (but I'll shut up) 15:55:47 ttx: ++ 15:55:48 dansmith: even we remove the projects versions things which is separate discussion though, I do not think we agreeing on what to use number of name 15:55:49 :-) 15:56:05 ttx +infinity:) 15:56:28 gmann: right, but it informs my opinion on how important it is to use another number with the name 15:56:41 ttx: it could be other way around too :) if number were used then switching to name could be in same boat 15:56:52 gmann: and I'm sorry for apparently reading that doc with a totally different interpretation.. my bad apparently 15:57:28 ttx: fwiw, I refer to ubuntu releases based on their number because it's so much easier to know the order and age 15:57:45 I can sometimes remember the lts release names, but never the intermediates 15:57:54 dansmith++ 15:58:05 yeah, both have their own pros and cons. numbers give is more time-relation to release 15:58:15 like I can look at my system still running 12.04 and feel the shame 15:58:42 I think that people just get used to names already and that's why they will not switch to numbers if name will still be used everywhere 15:58:46 ok 2 min left and I think we need re-discuss the naming/numbering things as we are back to ground on this 15:58:48 :-) Less shame in keeping a Bionic Beaver around? :-) 15:59:04 :D 15:59:09 johnsom: I definitely don't remember the animal, ever.. only the adjective.. good point 15:59:12 er, jungleboyj ^ 15:59:20 :-) 15:59:38 should we meet on call to figure that out? 15:59:44 adhoc meeitng? 16:00:09 i think the other thing we need to address is what we have asked the foundation to do exactly 16:00:23 yeah, I think there has been a lot of change since we had all this discussion initially, so we might want to have a specific voice call about it 16:00:25 i thought we wanted them to come up with a name following our criteria 16:00:28 dansmith: sure -- and yet they use the name during the development cycle and in the branch names :) 16:00:32 ? that is clear right. they will handle the name 16:00:44 gmann: I thought so. 16:00:57 yeah, but following alphabetical ordering? 10 char limit? no emojis? 16:01:01 rosmaita: come up with name as per the criteria they want 16:01:07 no emojis? That's it, I quit 16:01:12 I thought we had agreed to not remove the names. So, I think the question is whether we make the numbering more visible. 16:01:26 * jungleboyj laughs at ttx 16:01:30 jungleboyj: yeah 16:01:32 no, i thought they could use whatever *process* they want to find a name that meets our criteria 16:01:51 rosmaita: ++ 16:02:04 They are going to work on figuring out the naming process. 16:02:20 rosmaita: if they want to meet our criteria then what change made? just moving execution form TC to Foudnation. I think we said let foundation to come up with name and no TC involvement 16:02:33 yeah, they can pick our or their own 16:02:48 gmann: ++ 16:02:54 the change is that they will handle finding a name that meets our criteria 16:02:59 anyways we are going out of time. I will schedule a voice all sometime next week on this 16:03:06 like, we do expect them to keep the alphabetical ordering, right? 16:03:13 rosmaita: ++ 16:03:20 gmann: ++ 16:03:22 rosmaita: no, whatever they like to name :) 16:03:25 sorry but I have to leave now. I'm ok with adhoc meeting to discuss that once again if it will be needed 16:03:27 o/ 16:03:28 rosmaita: anyways we will discuss that too 16:03:34 ok 16:03:37 #topic Open Reviews 16:03:40 #link https://review.opendev.org/q/projects:openstack/governance+is:open 16:03:50 ^^ please review these, few of them are ready to vote 16:04:07 #link https://review.opendev.org/c/openstack/governance/+/840354 16:04:17 #link https://review.opendev.org/c/openstack/governance/+/840363 16:05:01 #action gmann to schedule 'release name things' discussion call *again* 16:05:11 let's close meeting. 16:05:20 thanks everyone for joining 16:05:26 Thanks! 16:05:26 #endmeeting