17:00:31 <gouthamr> #startmeeting tc
17:00:31 <opendevmeet> Meeting started Tue Nov 25 17:00:31 2025 UTC and is due to finish in 60 minutes.  The chair is gouthamr. Information about MeetBot at http://wiki.debian.org/MeetBot.
17:00:31 <opendevmeet> Useful Commands: #action #agreed #help #info #idea #link #topic #startvote.
17:00:31 <opendevmeet> The meeting name has been set to 'tc'
17:00:49 <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:52 <gouthamr> Today's meeting agenda can be found at https://wiki.openstack.org/wiki/Meetings/TechnicalCommittee
17:01:39 <gouthamr> #topic Roll Call
17:01:45 <gtema> o/
17:02:00 <noonedeadpunk> semi o/ - will need to leave in ~20m
17:03:12 <gouthamr> courtesy-ping:  frickler, spotz[m], cardoe, bauzas
17:03:24 <cardoe> o/
17:03:31 <gouthamr> noted absence: m n a sia d k a
17:03:35 <cardoe> Talking in a different channel. Sorry.
17:05:45 <gouthamr> no problem; i wonder if the meeting time's being an issue, or, its the end-of-year fever that gets us all :)
17:05:59 <gouthamr> our attendance is less than quorum, again.. lets get rolling
17:06:03 <gouthamr> #topic Last week's AIs
17:06:05 <noonedeadpunk> I think latter :)
17:06:33 <gouthamr> Reviews on TC resolution on os-net-config handover
17:06:49 <gouthamr> #link https://review.opendev.org/c/openstack/governance/+/967463
17:07:14 <gouthamr> this has a minimum number of votes and can merge anytime now, has been open 7 days..
17:07:23 <gouthamr> if you've not looked yet, please do
17:07:26 * bauzas joins late
17:07:49 <gouthamr> ah quorum!
17:08:17 <gouthamr> from the last week's meeting, i surmised that you wanted to move the FIPS Goal Objectives to the tracker
17:09:02 <gouthamr> it's already there :) i think i could do the patch today to move the goal back to "proposed" and start an ML thread with the actions we took at the PTG
17:09:51 <gouthamr> specifically, asking for help in redefining testing and completion of the goal, reviving failed testing, and stating that the TC is okay with project teams dropping failing jobs in the meantime
17:10:08 <gouthamr> did i miss anything?
17:12:05 <gouthamr> the next AI was regarding "PTL Appointment History", i think tonyb took this AI, but we didn't define it completely..
17:12:46 <gouthamr> a couple of weeks ago, we discussed a concern that PTL appointments must be preserved on projects.yaml.. and the AI was to write this down somewhere
17:13:13 <gtema> yes, also last week we were not  able to recall details
17:14:05 <fungi> right, the point was twofold
17:14:26 <fungi> first, a change in process so we stop wiping the prior list of appointments whena project switches from ptl to dpl model
17:14:46 <fungi> second, an audit of the git history to find past instances where that happened and restore the missing entries
17:15:55 <gouthamr> ah +1
17:16:34 <gouthamr> okay, tonyb has this detail in the scrollback now, ty fungi
17:16:59 <gouthamr> next AI was to finish working on the Monasca cleanup patches
17:17:37 <gouthamr> this looks green now, ty for the deep work on it, frickler:
17:17:40 <gouthamr> #link https://review.opendev.org/q/hashtag:%22monasca-retirement%22+(status:open%20OR%20status:merged)
17:18:21 <gouthamr> i messed up the cleanup, i left the LICENSE file in each repo, bad regex :/ so our validation script is failing
17:18:26 <gouthamr> #link https://review.opendev.org/c/openstack/governance/+/953671
17:19:06 <gouthamr> but, i don't want to go and delete those files and adjust the README.rst files etc (because we call out that the repo contents can be restored by checking out HEAD^1)
17:19:17 <gouthamr> so i added the repos to an ignore list here:
17:19:19 <gouthamr> #link https://review.opendev.org/c/openstack/governance/+/968268
17:19:57 <fungi> a more future-proof approach would be to stop explicitly referring to `git checkout HEAD^1` in the final readme and just use wording that indicates the last pre-retirement state is found in the branch's git history
17:20:18 <gouthamr> that would be nice
17:20:22 <fungi> we already have a ton of long-ago retired repositories for which it's no longer accurate anyway due to later changes merging
17:21:39 <gouthamr> fair, that wording is here: https://docs.opendev.org/opendev/infra-manual/latest/drivers.html#step-2-remove-project-content
17:22:15 <fungi> i'm happy to review an adjustment to that
17:22:16 <gouthamr> we didn't need to follow that to the letter, its just a suggestion
17:22:25 <gouthamr> and was easy to copy-pasta
17:22:57 <fungi> also openstack could just record a template of its own somewhere like https://docs.openstack.org/project-team-guide/repository.html#step-2-remove-project-content
17:23:19 <gouthamr> yeah..
17:23:42 <fungi> but in this case i do think the wording in infra-manual would be fine to adjust to something more loose, as long as it stays project-neutral
17:24:41 <gouthamr> +1.. so these patches could merge soon, if you'd like to review, please do..
17:25:20 <gouthamr> the next AI was regarding an openstack-discuss ML thread pointing to repositories using passlib to track its removal - was assigned to gtema
17:25:43 <gtema> oh yes, haven't done this yet, but improved analysis
17:25:58 <gtema> I updated the PQC wiki adding first actions
17:26:19 <gtema> will create 4 patches tomorrow agains requirements repo
17:26:57 <fungi> oh, that reminds me, someone reached out to me wanting to get more involved in security sig activities, and was specifically interested in helping with the pqc stuff
17:27:39 <fungi> i guess jp's ml thread would be a good starting point for them to get up to speed on it
17:28:11 <gouthamr> nice, ty for the updates on this
17:28:19 <fungi> but helping with stuff like passlib replacement would probably be a great place to jump in
17:28:22 <gouthamr> ++
17:28:45 <gtema> there is nothing to do with passlib since it is technically eliminated, just need to cleanup requirements
17:28:50 <gouthamr> #link https://wiki.openstack.org/wiki/Post_quantum_openstack
17:28:50 <gouthamr> #link https://lists.openstack.org/archives/list/openstack-discuss@lists.openstack.org/thread/NH7SVJHLRA4ZLH4UINXULFX5SXKVDPZK/ (ML thread on PQC)
17:29:31 <gouthamr> probably usage in projects that don't adhere to global requirements, mn asiadka mentioned needing to cleanup kolla-ansible
17:29:34 <fungi> oh, even better (re: passlib)
17:30:27 <gouthamr> there's this too: https://opendev.org/openstack/bifrost/src/branch/master/playbooks/roles/bifrost-ironic-install/tasks/install.yml#L67
17:30:28 <bauzas> thanks for the work on that
17:30:49 <cardoe> I’ve got to step away
17:31:02 <gouthamr> ack cardoe.. ty for joining us
17:31:35 <gouthamr> that's a wrap on AIs
17:31:57 <gtema> gouthamr - I know there are few cases of tooling still installing it, but we "agreed" last week to just get rid of it in requirements and send out info through the ML - which is what I'll do tomorrow
17:32:12 <gtema> unless the world explodes tomorrow again
17:32:16 <gouthamr> ty gtema
17:32:27 <gouthamr> gtema: no that's scheduled for day after tomorrow
17:32:47 <gouthamr> #topic OS Manuals could use reviews/help
17:32:51 <gouthamr> #link https://review.opendev.org/q/project:openstack/openstack-manuals+status:open
17:33:26 <gouthamr> think we had an impasse regarding this: https://review.opendev.org/c/openstack/openstack-manuals/+/905614
17:33:54 <gouthamr> and a related item on oslo's plate: https://review.opendev.org/c/openstack/openstackdocstheme/+/905613
17:35:31 <gouthamr> is there a way to compromise on this? Can we advertise that we're tracking users to generate metrics and help us improve OpenStack; and suggest how to disable this tracking?
17:35:53 <fungi> while those are changes i pushed, i have no vested interest in either approach (accepting them or ripping that stuff out entirely)
17:37:17 <gouthamr> my view is that i'd accept the changes and then seek another change to rip them out..
17:37:42 <gtema> than leave such review
17:37:44 <fungi> tonyb also pointed out that we have similar outdated scripts in the openstack wiki theme which would need to be redone for one of the more recent versions we're planning to upgrade through
17:38:49 <gouthamr> is the wiki theme maintained on git too?
17:39:12 <fungi> no
17:39:46 <fungi> we don't (yet) have any config management/deployment automation for the mediawiki server, that's something tonyb has been working on
17:40:06 <gouthamr> so technically, there are aspects that can be changed, enabled/disabled without any of us needing to review
17:40:11 <fungi> right
17:40:46 <fungi> it's something that was manually set up by a wmf staffer when we converted from moinmoin to mw, and they had committed to managing the server themselves back in the days before we insisted on having configuration management
17:41:33 <fungi> but then they moved on to other things and the server has been semi-abandoned since
17:42:17 <fungi> because turning a giant pile of php into a configuration-managed system wasn't anything the rest of us had time for
17:42:37 <gouthamr> yeah :( yet its a significant resource for the community
17:42:59 <gouthamr> are there any other opinions to note wrt this change?
17:44:26 <gouthamr> two +2s would mean it can be merged; i'll add mine and close it out unless you tell me we need a bit longer to consider it
17:45:59 <gouthamr> #topic Python PTI and test runner guidance
17:46:03 <gouthamr> #link https://lists.openstack.org/archives/list/openstack-discuss@lists.openstack.org/thread/3V3CNPQLB77SKFVLZ6LXJ5NPNYWW4QFD/ (Request for guidance on improving Python PTI doc to include pytest for Horizon plugins testing)
17:47:32 <gouthamr> think this thread went in different directions and i learned a few new things
17:48:26 <fungi> the resolution seems to be where chandan says "Watcher team is going with unittests module for writing watcher-dashboard integration tests."
17:48:52 <gouthamr> i think we've established that there's no problem pursuing pytest based tests, and we're asking the horizon team to explore if those tests can be run with stestr
17:49:35 <gtema> nope - stestr is not part of the issue at all
17:49:45 <gtema> not the runner is the "question", but the test itself
17:50:09 <gtema> we have projects using pytest to run unittests already
17:50:58 <fungi> right, pytest the runner is compatible with the unittests module's interfaces. pytest the module has additional test building blocks that don't work with a lot of other test runners
17:51:52 <clarkb> this situation is one where I think we should start from our goals first
17:52:05 <clarkb> whether or not anyone is using it already is beside the point.
17:52:25 <gtema> +1
17:52:26 <clarkb> and as I stated on the mailing list thread I don't think pytest is in opposition to the goals we have today
17:53:09 <bauzas> why people want to use pytest ?
17:53:09 <clarkb> specifically being able to run in parallel to take advantage of test resources and the ability to run in places like IDEs
17:53:09 <fungi> prior discussions also uncovered that the horizon team's implementation was due to the developers who wrote it not being familiar with existing convention within openstack, and then the team simply didn't want to redo that work later once it was already written
17:53:19 <bauzas> just an open question
17:53:51 <gtema> bauzas - because it is usually simpler, and slimmer
17:53:52 <gouthamr> yes, so its reasonable to ask if they can run these tests in parallel, and produce a subunit o/p
17:53:54 <clarkb> bauzas: pytest the test runner has some generally nice features for developers when debugging tests. Pytest the library is a lot less verbose than unittest the library
17:54:33 <bauzas> well, I can pdb dito ;-)
17:55:08 <clarkb> in the thread fixture creation management was specifically called out
17:55:26 <clarkb> you can totally write fixtures taht work with unittest and don't rely on pytest, but it sounds like people like the pytest fixture approach
17:56:12 <clarkb> gouthamr: yes that seems reasonable: basically capture that our assumptions are correct then move on
17:56:49 <gouthamr> #link https://governance.openstack.org/tc/reference/pti/python.html#python-test-running
17:57:58 <gouthamr> i think we can lead the discussion there, i agree that if this is encoded in the CI jobs, it'll catch the introduction of weird incompatible patterns/plugins that're possible with pytest
17:59:06 <gouthamr> anything else to round up this discussion?
17:59:23 <gtema> gouthamr - there are already quite a few projects using pytest instead of stestr, so this "guideline" is not fulfilled anymore
18:00:54 <gouthamr> yes; i think we did a code search to identify these
18:01:45 <frickler> oops, I messed up meeting timing again. I blame downstream noise. reading backlog now
18:01:58 <gouthamr> np frickler; its time to wrap up
18:02:08 <gouthamr> anything to note for the minutes today?
18:02:58 <fungi> the other projects brought up as existing examples of pytest use within openstack were cases in which the implementation was written before the projects became part of openstack, so essentially inherited/transplanted use
18:03:44 <fungi> not that it's necessarily a problem, just context
18:03:47 <gouthamr> ++
18:04:04 <gouthamr> okay, thank you all for joining.. i'll punt the rest of the topics to next week
18:04:19 <gouthamr> if there's anything pressing, please do continue the discussion here
18:04:22 <gouthamr> #endmeeting