18:00:12 #startmeeting tc 18:00:12 Meeting started Tue Sep 26 18:00:12 2023 UTC and is due to finish in 60 minutes. The chair is JayF. Information about MeetBot at http://wiki.debian.org/MeetBot. 18:00:12 Useful Commands: #action #agreed #help #info #idea #link #topic #startvote. 18:00:12 The meeting name has been set to 'tc' 18:00:15 #topic Roll Call 18:00:16 #topic Roll Call 18:00:27 o/ 18:00:28 Welcome to the weekly meeting of the OpenStack Technical Committee. A reminder that this meeting is held under the OpenInfra Code of Conduct available at https://openinfra.dev/legal/code-of-conduct. Today's meeting agenda can be found at https://wiki.openstack.org/wiki/Meetings/TechnicalCommittee 18:00:28 o/ 18:00:36 \o 18:00:46 We have one noted absence: Dan Smith. 18:01:03 o/ 18:01:29 o/ 18:02:23 We seem to have quorum; moving to agenda items. 18:02:45 #info There are no action items from Sept 19, 2023 meeting to follow up on, skipping agenda item. 18:02:52 #topic Gate Health Check 18:02:59 How's CI? 18:03:08 it is better this week and no such frequent or blocking failure 18:03:30 it is good it is going smooth during release time, hoping no surprise in this week :) 18:03:35 Wonderful; that matches my experience as well. Going to give a couple minutes for additional observations. 18:03:37 not everywhere. I know that in neutron we have pretty broken CI jobs 18:04:00 trunk live migration tests was failing frequently but that is skipped for now with open bug 18:04:05 ykarel suspects that it may be related to the latest release of the os-vif but it's still under investigation 18:04:11 slaweq: oh, live migration tests or other failure 18:04:17 o/ 18:04:21 i see 18:04:22 gmann other 18:04:44 Thank you slaweq for that update; if there's any assistance that can be provided please ask. 18:04:48 o/ 18:04:50 Any further CI updates? 18:05:10 devstack and greande branches cut are in progress 18:05:41 once they get merged then we will setup those for stable/2023.2 and master but till then both test the same thing 18:06:04 that is all from my side 18:06:40 Thanks for the update on devstack and grenade. Anything further before we move on? 18:06:54 we've been avoiding making any significant changes from the opendev side of things until the release is done 18:07:47 Thanks for that; I believe we can move on from CI now 18:07:57 yeah 18:07:59 #topic Leaderless projects 18:08:29 count: 13 18:08:39 I have some questions about this, too 18:08:44 it seems we have many late/invalid candidacy which is case in every election 18:09:09 is there a time until the PTL appointments have to be made? 18:09:11 we should create the etherpad and start tracking those 18:09:45 Does someone want to take ownership of this item, to document the leaderless projects and report status on them? 18:09:51 frickler: it should be done asap we find the leaders. there is no deadline as such 18:09:59 JayF: I can do 18:10:22 my idea would be to have some preconditions, like zuul errors fixed, release patches merged ... 18:11:07 We do already have a process for that, somewhat, via voting on the PTL nomination patches. 18:11:37 I encourage all TC members to make an effort to ensure that volunteer PTLs are active in the project with a history of being responsive to issues and reviewing code from common contributiors. 18:11:38 yeah, we can block the appointment if project does not seems active and gate failing or so and PTL not fixing those but just volunteer to apoointment 18:12:03 and even in etherpad also we can check and add our finding about project 18:12:15 o.k., so I'll collect some date to add to the etherpad 18:12:22 *data 18:12:25 not all project has to have leaders and if they are inactive and we do not get commitment from incoming PTL we can think of retiring those 18:12:46 frickler: ++ 18:12:51 or DPL 18:13:26 Thanks for that; I look forward to seeing what you all get put together. 18:13:27 DPL does not help here, PTL or DPL is different situation where nobody want to be PTL but have many maintainers to share PTL tasks 18:13:57 will create etherpad with all possible options 18:13:57 The main goal, I think, is to ensure every project has one or more attentive cores who can land projects; I think it's clear there are cases where that's not true today and we should avoid that in the future. 18:14:16 regardless of if the projects are PTL or DPL 18:14:20 **land patches 18:14:23 true 18:14:37 DPL cannot be excuse to keep project inactive 18:14:45 but I also have a question regarding DPL: this states that a per-cycle activity check should happen, is this still happening? https://governance.openstack.org/tc/resolutions/20200803-distributed-project-leadership.html#liaison-assignment-duration 18:14:54 #action gmann To create leaderless projects etherpad with information about leaderless projects 18:16:09 frickler: as we do not have liaison mdoel now, we have not done this explicitly but there are only few DPL project and we know the status of those. 18:16:22 but it will be good thing to do a check in PTG or right after election 18:17:28 frickler: since my tenure on the TC, now about a year, I have not been privvy to any systemmatic checking of project status, outside of what is happening now-ish around ensuring all projects are able to be released with upper-constraints + updated oslo libs 18:17:36 only three 1. oslo 2. release management 3. requirement and all are actove 18:17:38 active 18:17:49 triepleO also but that is already deprecated 18:17:58 the release team is fine, but I'd consider all three other DPL projects questionable 18:18:07 I would ask if there's further discussion on this topic, can we please hold it for open discussion? 18:18:19 oslo have some maintainers but yes we need more 18:18:20 I'd like to continue through the agenda before getting too far down the road on a tangent. 18:18:36 (that's literally one item away) 18:18:45 #topic Call for volunteers for Vice-Chair 18:19:10 As the new chair, I have to appoint a vice-chair. I'd like to request any interested volunteers to please speak up now, or to me in private. 18:19:25 is there some nomination period for this? 18:19:44 As documented; once a vice-chair is appointed by me, I push up a change to mark their role as vice-chair. 18:19:49 It is an appointed, not elected position. 18:20:03 In practice, someone volunteers to learn about chair responsibilities and gets in a position to hold the chair in the future. 18:20:12 yeah, it can be done anytime chair find vice-chair 18:20:31 yes, but maybe if I say I'd need to think about it for a week, would that be too long? 18:20:56 That is up to the chair to decide. 18:21:12 We don't have an official period that requires a vice-chair selection. 18:21:15 frickler: that is dangerously close enough to volunteering yourself that the likelyhood of others stepping up just went down ;) 18:21:20 at times there have also been more than one vice-chair. also there's probably nothing stopping the chair from adding and removing vice-chairs throughout their term, at their discretion 18:21:25 hehe 18:21:52 frickler: I think you'd be a good vice-chair, I'm willing to wait a bit for you to decide for sure, but lets have a chat together during that week at least? 18:21:56 yes, its appointment and can be changed within cycle 18:22:05 JayF: ack 18:22:10 I mainly dislike the idea of not having backup, personally, that's the rush for me. 18:22:12 frickler: ++ 18:22:28 JayF: we all got your back! 18:22:28 Either way, going to move on topics because I think there's not a lot of discussion left here. 18:22:36 #topic Open Discussion and Reviews 18:22:39 two items noted here 18:22:41 I can act as backup until we have a formal volunteer. 18:23:13 #info TC members and all interested OpenStackers need to register for the PTG. 18:23:20 #link https://openinfra.dev/ptg/ 18:23:37 Also, we have a small number of open reviews, please ensure to look over them. 18:23:39 #link https://review.opendev.org/q/projects:openstack/governance+is:open 18:23:43 Anyone can cover running the meetings I think, no worries JayF 18:24:46 frickler: This would be a good time to continue down the previous discussion path, as we are at the end of the agenda 18:24:58 frickler: if you have any desire for further discussion on DPL-based projects, and their status 18:25:17 Same for others; now is a good time to bring topics up that didn't make the agenda. 18:25:40 yeah, so one issue I have with tripleo is the number of zuul config errors 18:25:56 is there a plan yet for actual retirement? 18:27:08 triple-o should only be running on stable/wallaby, i thought 18:27:22 except for all their single-branch deliverables 18:27:31 things like like tripleo-ci 18:27:43 yeah, that is deprecated and we just kept it for stable/wallaby 18:28:10 i suppose we could delete zuul configuration out of all the other branches on the branched projects though 18:28:17 we should retire it asap stable/wallaby move to EOL which can be done immediately as per the new EM/EOL branch model 18:29:08 once we enforce the new model for stable branches of EM->unsupported then it should get cleanup 18:29:16 https://zuul.opendev.org/t/openstack/config-errors?project=openstack%2Ftripleo-ci&project=openstack%2Ftripleo-upgrade 18:29:32 keep in mind that you're effectively telling them to take maintenance of the wallaby version completely downstream at that point (not that i think that's a bad thing) 18:29:40 So, to restate and ensure the understanding is correct before I put it in the minutes; tripleo only supports stable/wallaby. It's going to get cleaned up when unsupported resolution is implemented as we'll retire stable/wallaby and the single branch projects which only exist to support that stable/wallaby tripleo 18:29:57 The only way this could/would change is if tripleo PTL opts-in to unmaintained 18:30:02 which requires them to fix CI and zuul config errors 18:30:11 yes 18:30:24 and i think also requires them to also keep all newer branches open? 18:30:28 if they opt-in for stable/wallaby then it should be fixed all 18:30:38 so post-release, it seems we'll have a forcing function to resolve CI either through deletion 18:31:00 does the new model allow them to opt into unmaintained stable/wallaby but eol xena etc? 18:31:07 I was going to say "or opt-in to unmaintained/" but I guess that's a good point, fungi, that would generally require the project to support newer branches 18:31:31 > No SLURP branches may be skipped between the oldest unmaintained branch and the current maintained releases. This makes sure operators have an upgrade path from one SLURP to the next all the way to maintained releases. 18:31:36 humm this makes tripleO case complicated 18:31:37 per https://governance.openstack.org/tc/resolutions/20230724-unmaintained-branches.html 18:31:53 they clearly mentioned that they cannot maintain any other branch than wallaby 18:32:01 They won't have any releases, so technically they're not missing any releases 18:32:13 well, it doesn't make the tripleo case complicated if you tell them any continued maintenance has to happen downstream so that we can eol it all upstream 18:32:22 And can keep maintaining Wallaby. 18:32:30 I suggest someone take an action to contact tripleo PTL, ask about their intentions, and we follow-up next meeting? 18:32:43 that is what retirement is but they want wallaby to maintain in upstream 18:32:51 Lets find out the actual likely outcome before exploring the entire problem space; that might save us some time? 18:33:15 e.g. if tripleo PTL and team are OK with retirement at this point; this is a much simpler question 18:33:31 it's DPL ;) 18:33:32 if we enforce requriement of all newer branches then it has to be retire 18:33:39 yeah no PTL for them 18:33:53 frickler: "email the PTL" for a DPL project, in my opinion, is effectively to email all the DPLs IMO 18:34:09 or at least the release management dpl in this case 18:34:11 we already discussed this a lot and got their view. it came up that they cannot maintain anything other than stable/wallaby 18:34:35 The question is not that gmann; it's "do you wish to continue maintaining stable/wallaby after this release, if permitted?" 18:34:35 it is up to us to retire it completely if that does not fit in our policy 18:34:43 right, the question is whether they still plan to continue maintaining stable/wallaby (but also when pressed they realized that they have projects they need to maintain master branches on as well() 18:34:44 if the answer is yes, we have the question about if policy allows it 18:35:04 JayF: last time they mentioned they have customer and want to maintain until wallaby is EOL 18:35:23 Wallaby is EOL if they don't opt in to unmaintained branches. EOL is decided project by project in this model. 18:35:31 it's entirely possible their desire to keep maintaining stable/wallaby upstream has changed now that they've released their replacement for tripleo 18:35:37 if we do wallaby EOL for all other projects then they might be ok to do so and retire completly 18:36:08 yeah, that is possible 18:36:21 I have a concrete proposal: contact TripleO DPLs, ask if they wish to continue maintaining stable/wallaby TripleO *and* the master-branch projects it relies on, use that information to continue to the next step. 18:36:39 In lieu of volunteers or alternate actions; I will take this action item and bring information back next week if they are responsive. 18:37:00 Is there any objection or alternative proposal? 18:37:18 ++, good plan. 18:37:37 for that proposal, i would clarify that it shouldn't make promises that they'll be able to do that, just that the tc will use that information in the decision-making process 18:38:11 I think we should have our new model documented/enforce so that they understand it clearly 18:38:38 (and that not only limited to specific projects) 18:38:49 as per current documented and release page stable/wallaby is still EM 18:39:16 That's a good point. We likely need a TC member to step up and update those documentation items before we can consider enforcement. 18:39:17 they should not think it will continue as EM and so they can say we will keep it open 18:39:20 oh, i see, you mean adjust the releases.openstack.org site to match up to the new policy 18:39:28 yeah 18:39:32 not that there are missing parts of policy documentation 18:39:42 Although, for purposes of contacting triplo DPLs, I think https://governance.openstack.org/tc/resolutions/20230724-unmaintained-branches.html will suffice 18:39:45 yes, that also need to update 18:39:50 but I appreciate you bringing up a needed action we shuld take, and likely soon 18:40:29 I am working on those actions. 18:40:30 * slaweq needs to leave a bit earlier today. Sorry and see You online o/ 18:40:43 Updating docs/releases to reflect new Unmaintained policy. 18:40:56 #action knikolla To work on updating releases.openstack.org to reflect new unmaintained branch policy ( https://governance.openstack.org/tc/resolutions/20230724-unmaintained-branches.html ) 18:41:09 Thanks for noting that down :) 18:41:41 #action JayF to contact TripleO DPLs to determine their desired state for TripleO maintenance next cycle 18:42:18 frickler: I will ensure that contact includes a link to the zuul-config-errors that are impacting 18:42:44 JayF: ack, thx 18:42:46 Any additional topics for Open Discussion? 18:42:54 PTG :) 18:43:08 We need to book slots, decide on number of slots and prepare agendas. 18:43:49 knikolla: Do we even have an etherpad for it yet? 18:43:59 I am not up to speed yet on PTG planning for TC in Caracal. 18:44:15 Not as of yet. 18:44:49 I'm going to create one real quick so we at least have a place to gather information; then I'll ensure it's a top level agenda item for next meeting. 18:45:06 #link https://etherpad.opendev.org/p/tc-ptg-october-2023 18:45:21 ++ 18:45:38 Great! 18:46:08 thank you for getting that on the radar knikolla 18:46:59 np, you can use the etherpad from prior PTGs as a rough template. I'm happy to help. 18:47:14 Thank you, I appreciate it and will absolutely take you up on that offer. 18:47:20 Any other items for discussion? 18:47:21 I'd also like to see other members' opinion on https://review.opendev.org/c/openstack/governance/+/895160 , not sure whether to continue in the review or here, maybe next time 18:47:37 python3.8 deprecation/EOL/support 18:47:56 yeah 18:48:07 it will be good to add feedback in gerrit 18:48:08 With the incoming PTG not too far that seems a good topic for a session with the community. 18:48:21 IMO, we can continue py3.8 in this release also 18:48:27 until it is EOL 18:49:16 I'll note, 3.8 is scheduled to be supported through October, 2024. So supporting it for Caracal means we'd support it for the full 2023.1->2024.1 slurp 18:49:26 which potentially seems like it could bring value 18:49:35 I do not know enough detail to have a strong opinion though. 18:49:49 re: https://peps.python.org/pep-0569/#lifespan 18:50:11 frickler: gmann: I think we should continue in that gerrit review; I will add putting a vote on that to my todo list. 18:50:22 Please other tc-members; take notice of the discussion in https://review.opendev.org/c/openstack/governance/+/895160 18:51:01 Anything further on that, or other topics for open discussion? 18:52:04 i think we should discuss this at the PTG: https://lists.openstack.org/pipermail/openstack-discuss/2023-September/035183.html 18:52:14 gmann handled the short-term issue, i think 18:52:32 I added that link to the PTG etherpad; we can expand on the topic async. Good callout. 18:52:35 but we should probably give the larger issue some consideration 18:52:37 ack, I also wanted to discuss the reqs team in that context 18:52:37 cool 18:53:10 short term, all needed reqs patched have merged 18:53:16 Yeah, I appreciate the work releases and oslo team do even more now; after trying to get oslo.messaging fixes out. 18:53:28 You really get a birds-eye view of the multiplicative complexity that can surface 18:53:48 yeah, those change merge is just small part but I agree we should discuss it broadly and give enough time 18:54:23 rosmaita: thanks for brining up 18:54:49 Approximately five minutes left; anything else on this or any other topic? 18:57:14 Have a nice day everyone o/ 18:57:15 #endmeeting