18:00:12 <JayF> #startmeeting tc
18:00:12 <opendevmeet> 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 <opendevmeet> Useful Commands: #action #agreed #help #info #idea #link #topic #startvote.
18:00:12 <opendevmeet> The meeting name has been set to 'tc'
18:00:15 <JayF> #topic Roll Call
18:00:16 <JayF> #topic Roll Call
18:00:27 <slaweq> o/
18:00:28 <JayF> 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 <gmann> o/
18:00:36 <frickler> \o
18:00:46 <JayF> We have one noted absence: Dan Smith.
18:01:03 <rosmaita> o/
18:01:29 <jamespage> o/
18:02:23 <JayF> We seem to have quorum; moving to agenda items.
18:02:45 <JayF> #info There are no action items from Sept 19, 2023 meeting to follow up on, skipping agenda item.
18:02:52 <JayF> #topic Gate Health Check
18:02:59 <JayF> How's CI?
18:03:08 <gmann> it is better this week and no such frequent or blocking failure
18:03:30 <gmann> it is good it is going smooth during release time, hoping no surprise in this week :)
18:03:35 <JayF> Wonderful; that matches my experience as well. Going to give a couple minutes for additional observations.
18:03:37 <slaweq> not everywhere. I know that in neutron we have pretty broken CI jobs
18:04:00 <gmann> trunk live migration tests was failing frequently but that is skipped for now with open bug
18:04:05 <slaweq> ykarel suspects that it may be related to the latest release of the os-vif but it's still under investigation
18:04:11 <gmann> slaweq: oh, live migration tests or other failure
18:04:17 <knikolla> o/
18:04:21 <gmann> i see
18:04:22 <slaweq> gmann other
18:04:44 <JayF> Thank you slaweq for that update; if there's any assistance that can be provided please ask.
18:04:48 <spotz[m]> o/
18:04:50 <JayF> Any further CI updates?
18:05:10 <gmann> devstack and greande branches cut are in progress
18:05:41 <gmann> 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 <gmann> that is all from my side
18:06:40 <JayF> Thanks for the update on devstack and grenade. Anything further before we move on?
18:06:54 <fungi> we've been avoiding making any significant changes from the opendev side of things until the release is done
18:07:47 <JayF> Thanks for that; I believe we can move on from CI now
18:07:57 <gmann> yeah
18:07:59 <JayF> #topic Leaderless projects
18:08:29 <frickler> count: 13
18:08:39 <frickler> I have some questions about this, too
18:08:44 <gmann> it seems we have many late/invalid candidacy which is case in every election
18:09:09 <frickler> is there a time until the PTL appointments have to be made?
18:09:11 <gmann> we should create the etherpad and start tracking those
18:09:45 <JayF> Does someone want to take ownership of this item, to document the leaderless projects and report status on them?
18:09:51 <gmann> frickler: it should be done asap we find the leaders. there is no deadline as such
18:09:59 <gmann> JayF: I can do
18:10:22 <frickler> my idea would be to have some preconditions, like zuul errors fixed, release patches merged ...
18:11:07 <JayF> We do already have a process for that, somewhat, via voting on the PTL nomination patches.
18:11:37 <JayF> 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 <gmann> 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 <gmann> and even in etherpad also we can check and add our finding about project
18:12:15 <frickler> o.k., so I'll collect some date to add to the etherpad
18:12:22 <frickler> *data
18:12:25 <gmann> 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 <gmann> frickler: ++
18:12:51 <spotz[m]> or DPL
18:13:26 <JayF> Thanks for that; I look forward to seeing what you all get put together.
18:13:27 <gmann> 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 <gmann> will create etherpad with all possible options
18:13:57 <JayF> 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 <JayF> regardless of if the projects are PTL or DPL
18:14:20 <JayF> **land patches
18:14:23 <gmann> true
18:14:37 <gmann> DPL cannot be excuse to keep project inactive
18:14:45 <frickler> 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 <JayF> #action gmann To create leaderless projects etherpad with information about leaderless projects
18:16:09 <gmann> 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 <gmann> but it will be good thing to do a check in PTG or right after election
18:17:28 <JayF> 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 <gmann> only three 1. oslo 2. release management 3. requirement and all are actove
18:17:38 <gmann> active
18:17:49 <gmann> triepleO also but that is already deprecated
18:17:58 <frickler> the release team is fine, but I'd consider all three other DPL projects questionable
18:18:07 <JayF> I would ask if there's further discussion on this topic, can we please hold it for open discussion?
18:18:19 <gmann> oslo have some maintainers but yes we need more
18:18:20 <JayF> I'd like to continue through the agenda before getting too far down the road on a tangent.
18:18:36 <JayF> (that's literally one item away)
18:18:45 <JayF> #topic Call for volunteers for Vice-Chair
18:19:10 <JayF> 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 <frickler> is there some nomination period for this?
18:19:44 <JayF> 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 <JayF> It is an appointed, not elected position.
18:20:03 <JayF> In practice, someone volunteers to learn about chair responsibilities and gets in a position to hold the chair in the future.
18:20:12 <gmann> yeah, it can be done anytime chair find vice-chair
18:20:31 <frickler> yes, but maybe if I say I'd need to think about it for a week, would that be too long?
18:20:56 <knikolla> That is up to the chair to decide.
18:21:12 <knikolla> We don't have an official period that requires a vice-chair selection.
18:21:15 <JayF> frickler: that is dangerously close enough to volunteering yourself that the likelyhood of others stepping up just went down ;)
18:21:20 <fungi> 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 <spotz[m]> hehe
18:21:52 <JayF> 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 <gmann> yes, its appointment and can be changed within cycle
18:22:05 <frickler> JayF: ack
18:22:10 <JayF> I mainly dislike the idea of not having backup, personally, that's the rush for me.
18:22:12 <gmann> frickler: ++
18:22:28 <rosmaita> JayF: we all got your back!
18:22:28 <JayF> Either way, going to move on topics because I think there's not a lot of discussion left here.
18:22:36 <JayF> #topic Open Discussion and Reviews
18:22:39 <JayF> two items noted here
18:22:41 <knikolla> I can act as backup until we have a formal volunteer.
18:23:13 <JayF> #info TC members and all interested OpenStackers need to register for the PTG.
18:23:20 <JayF> #link https://openinfra.dev/ptg/
18:23:37 <JayF> Also, we have a small number of open reviews, please ensure to look over them.
18:23:39 <JayF> #link https://review.opendev.org/q/projects:openstack/governance+is:open
18:23:43 <spotz[m]> Anyone can cover running the meetings I think, no worries JayF
18:24:46 <JayF> 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 <JayF> frickler: if you have any desire for further discussion on DPL-based projects, and their status
18:25:17 <JayF> Same for others; now is a good time to bring topics up that didn't make the agenda.
18:25:40 <frickler> yeah, so one issue I have with tripleo is the number of zuul config errors
18:25:56 <frickler> is there a plan yet for actual retirement?
18:27:08 <rosmaita> triple-o should only be running on stable/wallaby, i thought
18:27:22 <fungi> except for all their single-branch deliverables
18:27:31 <fungi> things like like tripleo-ci
18:27:43 <gmann> yeah, that is deprecated and we just kept it for stable/wallaby
18:28:10 <fungi> i suppose we could delete zuul configuration out of all the other branches on the branched projects though
18:28:17 <gmann> 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 <gmann> once we enforce the new model for stable branches of EM->unsupported then it should get cleanup
18:29:16 <frickler> https://zuul.opendev.org/t/openstack/config-errors?project=openstack%2Ftripleo-ci&project=openstack%2Ftripleo-upgrade
18:29:32 <fungi> 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 <JayF> 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 <JayF> The only way this could/would change is if tripleo PTL opts-in to unmaintained
18:30:02 <JayF> which requires them to fix CI and zuul config errors
18:30:11 <gmann> yes
18:30:24 <fungi> and i think also requires them to also keep all newer branches open?
18:30:28 <gmann> if they opt-in for stable/wallaby then it should be fixed all
18:30:38 <JayF> so post-release, it seems we'll have a forcing function to resolve CI either through deletion
18:31:00 <fungi> does the new model allow them to opt into unmaintained stable/wallaby but eol xena etc?
18:31:07 <JayF> 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 <JayF> > 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 <gmann> humm this makes tripleO case complicated
18:31:37 <JayF> per https://governance.openstack.org/tc/resolutions/20230724-unmaintained-branches.html
18:31:53 <gmann> they clearly mentioned that they cannot maintain any other branch than wallaby
18:32:01 <knikolla> They won't have any releases, so technically they're not missing any releases
18:32:13 <fungi> 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 <knikolla> And can keep maintaining Wallaby.
18:32:30 <JayF> I suggest someone take an action to contact tripleo PTL, ask about their intentions, and we follow-up next meeting?
18:32:43 <gmann> that is what retirement is but they want wallaby to maintain in upstream
18:32:51 <JayF> Lets find out the actual likely outcome before exploring the entire problem space; that might save us some time?
18:33:15 <JayF> e.g. if tripleo PTL and team are OK with retirement at this point; this is a much simpler question
18:33:31 <frickler> it's DPL ;)
18:33:32 <gmann> if we enforce requriement of all newer branches then it has to be retire
18:33:39 <gmann> yeah no PTL for them
18:33:53 <JayF> frickler: "email the PTL" for a DPL project, in my opinion, is effectively to email all the DPLs IMO
18:34:09 <fungi> or at least the release management dpl in this case
18:34:11 <gmann> 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 <JayF> The question is not that gmann; it's "do you wish to continue maintaining stable/wallaby after this release, if permitted?"
18:34:35 <gmann> it is up to us to retire it completely if that does not fit in our policy
18:34:43 <fungi> 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 <JayF> if the answer is yes, we have the question about if policy allows it
18:35:04 <gmann> JayF: last time they mentioned they have customer and want to maintain until wallaby is EOL
18:35:23 <JayF> Wallaby is EOL if they don't opt in to unmaintained branches. EOL is decided project by project in this model.
18:35:31 <fungi> 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 <gmann> if we do wallaby EOL for all other projects then they might be ok to do so and retire completly
18:36:08 <gmann> yeah, that is possible
18:36:21 <JayF> 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 <JayF> 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 <JayF> Is there any objection or alternative proposal?
18:37:18 <knikolla> ++, good plan.
18:37:37 <fungi> 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 <gmann> I think we should have our new model documented/enforce so that they understand it clearly
18:38:38 <noonedeadpunk> (and that not only limited to specific projects)
18:38:49 <gmann> as per current documented and release page stable/wallaby is still EM
18:39:16 <JayF> 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 <gmann> they should not think it will continue as EM and so they can say we will keep it open
18:39:20 <fungi> oh, i see, you mean adjust the releases.openstack.org site to match up to the new policy
18:39:28 <gmann> yeah
18:39:32 <fungi> not that there are missing parts of policy documentation
18:39:42 <JayF> Although, for purposes of contacting triplo DPLs, I think https://governance.openstack.org/tc/resolutions/20230724-unmaintained-branches.html will suffice
18:39:45 <gmann> yes, that also need to update
18:39:50 <JayF> but I appreciate you bringing up a needed action we shuld take, and likely soon
18:40:29 <knikolla> 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 <knikolla> Updating docs/releases to reflect new Unmaintained policy.
18:40:56 <JayF> #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 <knikolla> Thanks for noting that down :)
18:41:41 <JayF> #action JayF to contact TripleO DPLs to determine their desired state for TripleO maintenance next cycle
18:42:18 <JayF> frickler: I will ensure that contact includes a link to the zuul-config-errors that are impacting
18:42:44 <frickler> JayF: ack, thx
18:42:46 <JayF> Any additional topics for Open Discussion?
18:42:54 <knikolla> PTG :)
18:43:08 <knikolla> We need to book slots, decide on number of slots and prepare agendas.
18:43:49 <JayF> knikolla: Do we even have an etherpad for it yet?
18:43:59 <JayF> I am not up to speed yet on PTG planning for TC in Caracal.
18:44:15 <knikolla> Not as of yet.
18:44:49 <JayF> 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 <JayF> #link https://etherpad.opendev.org/p/tc-ptg-october-2023
18:45:21 <gmann> ++
18:45:38 <knikolla> Great!
18:46:08 <JayF> thank you for getting that on the radar knikolla
18:46:59 <knikolla> np, you can use the etherpad from prior PTGs as a rough template. I'm happy to help.
18:47:14 <JayF> Thank you, I appreciate it and will absolutely take you up on that offer.
18:47:20 <JayF> Any other items for discussion?
18:47:21 <frickler> 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 <frickler> python3.8 deprecation/EOL/support
18:47:56 <gmann> yeah
18:48:07 <gmann> it will be good to add feedback in gerrit
18:48:08 <knikolla> With the incoming PTG not too far that seems a good topic for a session with the community.
18:48:21 <gmann> IMO, we can continue py3.8 in this release also
18:48:27 <gmann> until it is EOL
18:49:16 <JayF> 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 <JayF> which potentially seems like it could bring value
18:49:35 <JayF> I do not know enough detail to have a strong opinion though.
18:49:49 <JayF> re: https://peps.python.org/pep-0569/#lifespan
18:50:11 <JayF> 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 <JayF> Please other tc-members; take notice of the discussion in https://review.opendev.org/c/openstack/governance/+/895160
18:51:01 <JayF> Anything further on that, or other topics for open discussion?
18:52:04 <rosmaita> i think we should discuss this at the PTG: https://lists.openstack.org/pipermail/openstack-discuss/2023-September/035183.html
18:52:14 <rosmaita> gmann handled the short-term issue, i think
18:52:32 <JayF> I added that link to the PTG etherpad; we can expand on the topic async. Good callout.
18:52:35 <rosmaita> but we should probably give the larger issue some consideration
18:52:37 <frickler> ack, I also wanted to discuss the reqs team in that context
18:52:37 <rosmaita> cool
18:53:10 <frickler> short term, all needed reqs patched have merged
18:53:16 <JayF> Yeah, I appreciate the work releases and oslo team do even more now; after trying to get oslo.messaging fixes out.
18:53:28 <JayF> You really get a birds-eye view of the multiplicative complexity that can surface
18:53:48 <gmann> yeah, those change merge is just small part but I agree we should discuss it broadly and give enough time
18:54:23 <gmann> rosmaita: thanks for brining up
18:54:49 <JayF> Approximately five minutes left; anything else on this or any other topic?
18:57:14 <JayF> Have a nice day everyone o/
18:57:15 <JayF> #endmeeting