| gouthamr | tc-members: a gentle reminder that our weekly IRC meeting will happen here in ~45 minutes. Agenda is here: https://wiki.openstack.org/wiki/Meetings/TechnicalCommittee | 16:13 |
|---|---|---|
| opendevreview | Ivan Anfimov proposed openstack/openstack-manuals master: Change tenant_network_types to project_network_types https://review.opendev.org/c/openstack/openstack-manuals/+/977833 | 16:19 |
| opendevreview | Ivan Anfimov proposed openstack/openstack-manuals master: Change tenant_network_types to project_network_types https://review.opendev.org/c/openstack/openstack-manuals/+/977833 | 16:20 |
| *** gmaan is now known as gmaan_afk | 16:29 | |
| opendevreview | Ivan Anfimov proposed openstack/openstack-manuals master: Change tenant_network_types to project_network_types https://review.opendev.org/c/openstack/openstack-manuals/+/977833 | 16:41 |
| gouthamr | #startmeeting tc | 17:00 |
| opendevmeet | Meeting started Tue Feb 24 17:00:21 2026 UTC and is due to finish in 60 minutes. The chair is gouthamr. Information about MeetBot at http://wiki.debian.org/MeetBot. | 17:00 |
| opendevmeet | Useful Commands: #action #agreed #help #info #idea #link #topic #startvote. | 17:00 |
| opendevmeet | The meeting name has been set to 'tc' | 17:00 |
| gouthamr | 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. | 17:00 |
| gouthamr | Today's meeting agenda can be found at https://wiki.openstack.org/wiki/Meetings/TechnicalCommittee | 17:00 |
| gouthamr | #topic Roll Call | 17:00 |
| spotz[m] | o/ | 17:00 |
| noonedeadpunk | o/ | 17:01 |
| gtema | o/ | 17:01 |
| frickler | \o | 17:01 |
| gouthamr | courtesy-ping: cardoe, bauzas | 17:02 |
| gouthamr | noted absence: m n a s i a d k a, t o n y b | 17:02 |
| cardoe | I'm here sorry. | 17:03 |
| gouthamr | alright, lets get started.. thanks for joining! | 17:04 |
| gouthamr | #topic Last Week's AIs | 17:04 |
| gouthamr | thanks for running the meeting noonedeadpunk! i didn't see any explicit AIs from the meeting last week | 17:05 |
| noonedeadpunk | there was none, yah | 17:06 |
| gouthamr | was glad to see the efforts to strengthen the requirements team; ty for the proposal frickler | 17:06 |
| gouthamr | we'll discuss the elections and leaderless teams in a little bit.. | 17:07 |
| gouthamr | was there anything that folks were working on from the past week/s? | 17:07 |
| gouthamr | alright, sounds like no.. | 17:08 |
| gouthamr | #topic 2026.2 Election | 17:08 |
| gouthamr | we're midway through the election process; we're currently in the TC campaigning week | 17:09 |
| gouthamr | #link https://lists.openstack.org/archives/list/openstack-discuss@lists.openstack.org/thread/KJZJMNNY437MRMSZHPEVDX73MBZYBCAA/ | 17:09 |
| gouthamr | ianychoi closed out the nomination period with that email ^ | 17:09 |
| noonedeadpunk | campaigning witout candidates and actual election is sad... | 17:10 |
| gouthamr | we had 5 TC seats, and 5 candidates, so there is no need for an election.. | 17:10 |
| gouthamr | noonedeadpunk: we've been here before.. retaining the campaigning period was intentional to have open discussions on the ML and air out any vision/goals, debate ideas.. but, this week is probably been a terrible one for it given we're at feature freeze at the same time | 17:11 |
| gouthamr | that said, election officials will post the patch formalizing the results tomorrow, which was supposed to be the start of the voting period | 17:11 |
| gouthamr | two project teams will have elections: barbican, horizon | 17:12 |
| fungi | barbican and horizon will have runoffs though, so the "campaigning" period gives election officials some time between close of nominations and polling to put together and check the rolls | 17:12 |
| gouthamr | +1 | 17:13 |
| frickler | and voters time to check their civs status ;) | 17:13 |
| spotz[m] | And Ian sent an opt in reminder | 17:13 |
| noonedeadpunk | ++ i was not saying we should not have campaigning, but that it[s sad there's no tc election | 17:14 |
| gouthamr | #link https://lists.openstack.org/archives/list/openstack-discuss@lists.openstack.org/thread/VYIAMX4PVUSE34IYNYFROA3HTYMDF6UH/ | 17:14 |
| gouthamr | noonedeadpunk: ah, yeah.. i was concerned up until the last minute | 17:14 |
| spotz[m] | I’m just glad we had enough candidates | 17:15 |
| noonedeadpunk | ++ | 17:15 |
| gouthamr | i don't know all the reasons why someone is or isn't on the TC :D but i am noodling on a mentoring plan | 17:15 |
| noonedeadpunk | though possibility to reduce amount of seats is still on the table I'd say | 17:15 |
| gouthamr | ? | 17:15 |
| noonedeadpunk | well, maybe we actually should think about it for the future | 17:16 |
| noonedeadpunk | and get the plan ready | 17:16 |
| noonedeadpunk | as whenever there're no elections, I think we are loosing connection with community | 17:16 |
| noonedeadpunk | or community has shrinked again | 17:17 |
| noonedeadpunk | to there's no reason to have same amount of representatives for smaller community | 17:17 |
| spotz[m] | We are inconsistent for sure | 17:18 |
| gouthamr | if we know that the size of the community has shrunk, that's a fair call... but, we track contributors and the trends have remained the same with slight increases in the past few cycles | 17:18 |
| gouthamr | we're surely dropping project teams, and we're on track to drop two more in the next cycle unless something changes | 17:19 |
| gouthamr | in my view is that there's a lot that the TC can/needs to do.. and we're limited by the amount of time we're able to dedicate... so a smaller TC in my view will affect that. | 17:20 |
| noonedeadpunk | yeah, fair point as well | 17:21 |
| spotz[m] | I know the timing is release based but that doesn’t mean it’s the best timing for holidays etc | 17:23 |
| gouthamr | gtema is ending his TC term.. i'd like to take a moment to thank him for reviving the discussion around keystone, security and bringing his expertise on openstackCLI/sdk and API design, automation and documentation to the TC.. | 17:24 |
| gouthamr | gtema: your frustration with bureaucracy will stick with me though :D as a PTL of multiple teams, i know you'll not be shy to linger here and continue to make noise! | 17:25 |
| gtema | :) | 17:25 |
| gouthamr | spotz[m]: true, we mechanically work backwards from the release date to schedule elections | 17:27 |
| gouthamr | but, we've definitely made enough noise about trying to get your nominations in before the holidays | 17:27 |
| gouthamr | the tracker for the rest of our discussion: | 17:29 |
| gouthamr | #link https://etherpad.opendev.org/p/2026.2-leaderless (Leaderless teams in 2026.2) | 17:29 |
| gouthamr | we don't need to make any decisions today, but, please do share any opinions on the etherpad.. some decisions may be easier than others | 17:30 |
| sean-k-mooney | oslo i bleivle inteded to stay with teh DPL model it just need a new release liason | 17:31 |
| sean-k-mooney | sinc ethey didnt reply | 17:31 |
| gouthamr | ack sean-k-mooney.. | 17:32 |
| sean-k-mooney | thats already noted in the ether pad for what its worth https://etherpad.opendev.org/p/2026.2-leaderless#L236 | 17:32 |
| gouthamr | damani's pretty active on the reviews and project maintenance, but, probably has gerrit notifications muted and was away during the week that we did the DPL reset | 17:33 |
| frickler | mistral and adjutant seem easy appointments to me. we might consider extending the activitity period to accomodate for more "senior" projects ... like extend to two years? | 17:33 |
| frickler | yes, the DPL reset was pretty rushed this time | 17:34 |
| gouthamr | +1 | 17:34 |
| gouthamr | yeah; "oops"-ed it under a week, so not a good move | 17:34 |
| gouthamr | but, was also thinking there could be more liaisons from the large core group in oslo.. folks could step up to do some "unseen" governance work.. make things more sustainable | 17:36 |
| * gouthamr will ask if they'd like that on that patch and on #openstack-oslo | 17:36 | |
| *** gmaan_afk is now known as gmaan | 17:37 | |
| frickler | the other option for activity might also to automatically make people doing +2 (or only +3?) review ACs? would require some coding work, but would certainly not be the wrong direction IMO | 17:38 |
| gouthamr | ^ i agree with this | 17:38 |
| spotz[m] | 2 years or 2 releases? | 17:38 |
| gouthamr | it's already 2 releases.. | 17:39 |
| frickler | 2 releases is what we have now. so 2 years or 4 releases | 17:39 |
| fungi | since the election tooling is already doing gerrit queries, extending that to check who voted how on changes wouldn't be hard | 17:39 |
| gouthamr | its super easy to author a small patch and fix/add _something_ and become an APC.. but ¯\_(ツ)_/¯ | 17:39 |
| gouthamr | yeah.. i think it'll be a good thing to do | 17:40 |
| gouthamr | fungi: would that also add folks to the contributor list that the staff generates at the end of a release? | 17:41 |
| fungi | yes | 17:41 |
| fungi | though if that's not desirable, it could be made a runtime option too | 17:41 |
| gouthamr | nice ++ i'm for it.. | 17:41 |
| frickler | that would be a good bonus, too, IMO | 17:41 |
| fungi | s/the staff generates/fungi generates/ so feel free to bug me with any concerns or suggestions anyway | 17:42 |
| gouthamr | haha.. | 17:42 |
| frickler | fungi: so you would you volunteer to look into the coding part? I would then volunteer to propose a policy change. but likely only in a couple of weeks when the new TC is seated | 17:43 |
| fungi | i can, sure | 17:45 |
| gouthamr | good stuff! ty frickler fungi | 17:45 |
| gouthamr | anything else for $topic today? | 17:46 |
| gouthamr | #topic A check on gate health | 17:47 |
| gouthamr | any gate updates to share today? | 17:47 |
| fungi | did the tox/packaging regression get solved? | 17:48 |
| * gouthamr hasn't seen any more issues on the "master" branch of repos | 17:49 | |
| frickler | also note that a big u-c update has merged yesterday (collected over the last three months) any weird failures might be related | 17:51 |
| clarkb | frickler: is that for the setuptools update? | 17:52 |
| clarkb | pkg_resources removal specifically | 17:52 |
| frickler | no, u-c updates for like 100 non-openstack dependencies | 17:52 |
| noonedeadpunk | this is good to know | 17:53 |
| frickler | #link https://review.opendev.org/c/openstack/requirements/+/965873 | 17:53 |
| frickler | even more -142+143 | 17:54 |
| fungi | wow | 17:54 |
| noonedeadpunk | I assume this is the last one before the release? | 17:54 |
| frickler | well reqs freeze starts this Friday, so unless we discover any major issues, yes | 17:55 |
| noonedeadpunk | yes, sure | 17:55 |
| sean-k-mooney | i wonder how many of those were fixing pkg_resouces... | 17:56 |
| frickler | there's still some new reqs additions pending, not sure yet what to make of them | 17:56 |
| noonedeadpunk | heh :D | 17:56 |
| frickler | also reqs stable branches are still borked, any de-borking help will be greatly appreciated | 17:58 |
| gouthamr | ack, we're at the hour | 18:00 |
| gouthamr | we'd to skip Open Discussion.. but, is there anything else you'd like to add to the minutes today? | 18:01 |
| gouthamr | alright, thank you for participating everyone | 18:02 |
| gouthamr | oh one thing! the TC chair position will need to be filled when we accept the results, so please do add your nominations if you're interested | 18:03 |
| gouthamr | see you here next week! | 18:04 |
| gouthamr | #endmeeting | 18:04 |
| opendevmeet | Meeting ended Tue Feb 24 18:04:05 2026 UTC. Information about MeetBot at http://wiki.debian.org/MeetBot . (v 0.1.4) | 18:04 |
| opendevmeet | Minutes: https://meetings.opendev.org/meetings/tc/2026/tc.2026-02-24-17.00.html | 18:04 |
| opendevmeet | Minutes (text): https://meetings.opendev.org/meetings/tc/2026/tc.2026-02-24-17.00.txt | 18:04 |
| opendevmeet | Log: https://meetings.opendev.org/meetings/tc/2026/tc.2026-02-24-17.00.log.html | 18:04 |
| clarkb | I've been unexpectedly AFK for a week and am slowly catching up on stuff. I know github was announcing the ability to disable pull requests. Do we know if they have added that feature yet and has anyone looked into maybe updating the zuul github jobs to disable them entirely rather than closing them with the zuul jobs? | 18:11 |
| fungi | i haven't seen any more about it | 18:11 |
| sean-k-mooney | clarkb: looking at the admin pannel on a personla repo yes | 18:12 |
| sean-k-mooney | there is now a tick box in the main setting view for pull requets | 18:13 |
| fungi | ooh! | 18:13 |
| sean-k-mooney | you can uncheck it or you can limit it to collaberators only | 18:13 |
| sean-k-mooney | its checked by defualt with all users set which was the old behvior | 18:13 |
| cardoe | I'm wondering if we can update some base jobs to better support pre-commit (or prek which is what I've moved to personally) | 18:14 |
| fungi | i guess we'll need to look at how that's instrumented in the api so that the zuul job which creates the mirror repositories on github can set them with pull requests off by default now | 18:14 |
| clarkb | fungi: ++ | 18:14 |
| clarkb | cardoe: I'm not sure what needs to be done? You can run pre commit with tox or nox then the existing stuff just works right? | 18:15 |
| fungi | i think it's the same one that is currently closing the pull requests | 18:15 |
| sean-k-mooney | cardoe: normally we just use tox to run it | 18:15 |
| cardoe | I've been wondering as well if we should update some of our Python docs which still talk about nose and talk about creating setup.py first then mention pyproject.toml later down. | 18:15 |
| sean-k-mooney | some of that has been updated semi recently in teh pti at least | 18:15 |
| sean-k-mooney | but probly not in the project creators guide | 18:15 |
| sean-k-mooney | https://github.com/openstack/governance/blob/master/reference/pti/python.rst | 18:16 |
| cardoe | well the way we run it with tox has been to have each project have a pep8 target which calls pre-commit | 18:16 |
| sean-k-mooney | now talks about using python -m build for example | 18:16 |
| cardoe | ah so that's another place. | 18:16 |
| sean-k-mooney | yes or in the lint target | 18:16 |
| sean-k-mooney | or linter | 18:16 |
| sean-k-mooney | it would not be hard to write a diffent job if you wanted too but doign it in pep8 was to have 1 job for all liniting checks | 18:17 |
| cardoe | https://docs.openstack.org/project-team-guide/project-setup/python.html | 18:17 |
| cardoe | That's another guide | 18:18 |
| cardoe | and then pbr has its own as well. | 18:18 |
| fungi | well, pbr's is for any project using pbr, not just openstack projects | 18:18 |
| cardoe | Just looking at centralizing or at least removing duplication and cross-linking maybe. | 18:18 |
| cardoe | Right. So those other docs could just link out to pbr. | 18:18 |
| sean-k-mooney | ya that still refence py27 :) so might be a littel out of date | 18:18 |
| fungi | similarly, the opendev infrastructure manual is for anyone adding projects to opendev, not just openstack specifically | 18:19 |
| sean-k-mooney | cardoe: if you do not want to run pre-commt via tox i woudl suggest using https://opendev.org/zuul/zuul-jobs/src/branch/master/roles/ensure-uv or https://opendev.org/zuul/zuul-jobs/src/branch/master/roles/ensure-pip and use uvx/pipx to install/run it driectly in a job | 18:21 |
| fungi | sean-k-mooney: we still run openstack-tox-py27 on pbr changes for the moment: https://opendev.org/openstack/pbr/src/branch/master/.zuul.yaml#L131 | 18:21 |
| cardoe | as far as running pre-commit (the author is quite hostile to the community so prek is my tool of choice) via tox is that we just add a bunch of extra cycles in Zuul. That's all. | 18:21 |
| cardoe | Cause the workers could have a cached copy and just run pre-commit and it'd be a quicker feedback loop. | 18:22 |
| * cardoe shrugs. | 18:22 | |
| fungi | cached copy of what? | 18:22 |
| cardoe | Isn't tox cached? | 18:23 |
| clarkb | no | 18:23 |
| sean-k-mooney | havent herd of https://github.com/j178/prek before now but is it compatible pre-commit. it claims to be a drop in replacment. creating a ensure-prek role would not be hard | 18:23 |
| sean-k-mooney | cardoe: its not but the pypi wheils it pulls are | 18:23 |
| sean-k-mooney | we have mirros at the ci providers but we are not cachign the dep that tox ues in teh images/jobs | 18:24 |
| clarkb | https://zuul.opendev.org/t/openstack/build/a71674c7083d45f7a4652ba2d6cc3cc4/log/job-output.txt#463 random job I see in the current dashboard showing where tox gets installed | 18:24 |
| cardoe | sean-k-mooney: yeah I switched to it when CPython switched to it. | 18:24 |
| fungi | if you re-run `pip install` (and hence anything that uses it, including tox) on the same machine, the downloads are cached. we don't rerun on the same machines for zuul jobs, we use a fresh un-contaminated machine on every run | 18:24 |
| fungi | as for pre-caching the tox installation, not every job runs the same version of tox, so we'd have to decide whether to cache multiple versions, ignore the cache for less commonly-used versions, et cetera | 18:26 |
| sean-k-mooney | tox also does build isolation in strage ways | 18:26 |
| sean-k-mooney | so caching it si sort of complicated | 18:26 |
| fungi | generally we don't pre-cache much on our test node images other than our git repositories (which then get updated at the last moment when the job starts), and a few files that tend to get re-used e.g. cirros test image files | 18:27 |
| cardoe | I've just been making some local changes to get a quicker turnaround loop for myself and I thought that some of that savings could be had by the CI. | 18:27 |
| sean-k-mooney | out of interst do you find it long at the moment? | 18:28 |
| clarkb | The main struggle with caching things ont he image side is it makes it difficult for us to change the image cache as that becomes an api that random jobs and projects end up relying on | 18:28 |
| clarkb | so we've tried to reduce that surface area down to what fungi describes | 18:28 |
| cardoe | so tox -> pre-commit is pretty slow. I used to do that for my git pre-commit hook. | 18:29 |
| fungi | have you profiled it to determine where the slowness is? | 18:29 |
| sean-k-mooney | ack locally i just install it or run it via uvx pre-commit run -a | 18:29 |
| cardoe | fungi: no. I just run prek directly and it's fractional amount of time. | 18:31 |
| sean-k-mooney | https://paste.opendev.org/show/bEoQZUW3aGYA4j9j809D/ | 18:32 |
| sean-k-mooney | so clean clone or ironci plues urnign it is under a miniute including the clone for me | 18:32 |
| fungi | anyway, an ansible task that runs it directly without relying on tox is a possibility, you'd just need to work out details like initial dependency setup and how and what logs to collect, which are already solved for the tox task | 18:35 |
| cardoe | You have better hardware than me. 97 seconds for me and 39 seconds for just plain prek. | 18:37 |
| fungi | also if you want it to do inline commenting in gerrit, parsing its output may have to be worked out separately | 18:38 |
| sean-k-mooney | cardoe: that fair with a primed cache for both tools there is effectivly no delta for me https://paste.opendev.org/show/bk4zAtvVnjgZTkSq6KBz/ | 18:38 |
| sean-k-mooney | so the hook output does not really change but i guess the curertn tooling is tied into parsing the tox output | 18:40 |
| fungi | yeah, having not used precommit i don't really know if that would need to be adapted or not | 18:41 |
| sean-k-mooney | cardoe: prek is packaged on pypi so it woudl be pretty trivial to create a role/job to use it direcly and turn that into a job. im probaly not going to have a chace to do that in the short term but i am activly updating cyborg pre-commit hooks so i might try to find a few minutes to hack somethign togheter | 18:47 |
| sean-k-mooney | if you work on one let me know and i might check it out but im not expecting it to really speed up ci but if it does it woudl be inetresting to know | 18:48 |
| cardoe | Just thought the job runs a lot on our CI and if it saved 66% of wall time I was just wondering if it would be acceptable to contribute something. | 18:48 |
| sean-k-mooney | that feels more like a project level disucssion then a tc one. you can always contibute somethign and dicuss it witht he relevent teams or bring it up in the qa channel perhaps. you might reach more intersted parties there | 18:50 |
| cardoe | Well just trying to standardize things which is why I mentioned it here. Plus I had asked clarkb about Python-y things here before. | 18:55 |
Generated by irclog2html.py 4.0.0 by Marius Gedminas - find it at https://mg.pov.lt/irclog2html/!