08:00:16 <mnasiadka> #startmeeting tc
08:00:16 <opendevmeet> Meeting started Tue Nov 18 08:00:16 2025 UTC and is due to finish in 60 minutes.  The chair is mnasiadka. Information about MeetBot at http://wiki.debian.org/MeetBot.
08:00:16 <opendevmeet> Useful Commands: #action #agreed #help #info #idea #link #topic #startvote.
08:00:16 <opendevmeet> The meeting name has been set to 'tc'
08:00:23 <mnasiadka> 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.
08:00:29 <mnasiadka> Today's meeting agenda can be found at https://wiki.openstack.org/wiki/Meetings/TechnicalCommittee
08:00:36 <mnasiadka> #topic Roll Call
08:00:38 <tonyb> o/
08:00:39 <mnasiadka> o/
08:00:48 <gtema> o/
08:02:24 <mnasiadka> courtesy-ping: gouthamr, noonedeadpunk, frickler, spotz[m], cardoe, bauzas
08:04:24 <mnasiadka> #topic Last Week's AIs
08:04:43 <mnasiadka> Analyze user survey results
08:05:06 <mnasiadka> We need a volunteer for this - if there are none - it will get moved to TC tracker (in the hope somebody wants to pick it up later)
08:06:17 <mnasiadka> Assuming no volunteers - will move it to the tracker after the meeting
08:06:19 <gtema> I can't see for myself  what can be useful in that data in that form
08:06:38 <tonyb> I'm curious what analysis there is for us to do? but happy let it move to the  tracker
08:07:04 <mnasiadka> Me neither, but it seems usually somebody from the TC did an analysis and published that
08:07:05 <mnasiadka> #link https://governance.openstack.org/tc/user_survey/analysis-2023.html
08:07:09 <mnasiadka> As an example
08:07:22 <gtema> it feels like a yet another survey where nobody has really idea what is this good for
08:08:02 <gtema> slaweq was preparing this overview if I recall correctly
08:08:08 <tonyb> I can see it's value for the foundation and for the TC in very specific cases
08:08:15 <mnasiadka> I personally feel the user survey has too many possible fields to fill out or the input is a bit vague (e.g. you can choose ‘Ansible’ as your deployment tool)
08:09:01 <gtema> the results analysis should be done by the people who came with those questions
08:09:13 <mnasiadka> Oh it surely should
08:09:22 <mnasiadka> But let’s move that to the tracker for now
08:09:34 <mnasiadka> Our discussion doesn’t really help in finding a solution for the analysis
08:09:52 <mnasiadka> Next one - Draft TC resolution on os-net-config handover (gouthamr)
08:09:58 <mnasiadka> #link https://review.opendev.org/c/openstack/governance/+/967463 (2025-11-17 Retirement and Handover of the `os-net-config` Project)
08:11:05 <tonyb> I'll add my views to the review but in general I don't think there's alot for the 3 of us on that one?
08:11:29 <gtema> indeed
08:11:47 <mnasiadka> Yeah, I just commented on this
08:11:49 <mnasiadka> Let’s move forward
08:12:01 <mnasiadka> Propose document change to redirect os-net-config docs link to git repo README (gouthamr)
08:12:18 <mnasiadka> No need to discuss that
08:12:31 <mnasiadka> Ok, next one is
08:12:32 <mnasiadka> Rework FIPS goal objectives and testing requirements (volunteer needed, move to tracker if no-one interested)
08:13:39 <mnasiadka> I personally have no interest in FIPS, given it’s for one country - is there any volunteer interested in FIPS? If no - we’ll move that to the tracker (given no traction/interest to date)
08:13:44 <gtema> oh lol - move everything to tracker ;-)
08:14:08 <tonyb> get that ^^ man a beer/coffee!
08:14:27 <mnasiadka> And then we send the tracker to /dev/null? lol
08:14:42 <tonyb> :D
08:14:46 <gtema> correct - that was a not-expressed thought
08:14:59 <mnasiadka> Well, let’s keep it recorded - but if there’s no interest - we can’t really do anything
08:15:08 <mnasiadka> Next one
08:15:10 <mnasiadka> Update/document procedure to preserve project appointment history (tonyb)
08:15:15 <mnasiadka> tonyb: any updates?
08:15:29 * tonyb has no recollection of this item
08:16:11 <mnasiadka> Hmm, that’s interesting - I think it came up regarding the recent telemetry PTL switch
08:16:23 <tonyb> Can we add a meta-AI for me to figure out what it is and then either do it or correct the AI
08:16:46 <tonyb> Sounds plausible
08:17:19 <mnasiadka> No other option - I’ll leave it in AIs on the wiki :)
08:17:29 <tonyb> \o/
08:17:36 <mnasiadka> Next one is: Clarify and document AI/LLM policy/instructions for Project Team Guide
08:17:48 <mnasiadka> But cardoe (who’s name is against the AI in the wiki) is not here
08:17:59 <mnasiadka> So let’s move on
08:18:08 <mnasiadka> Investigate adding ""archived"" state to retired PyPI projects (volunteer needed, move to tracker if no-one interested)
08:18:41 <tonyb> I can look at that.  I'm not 100% certain of the value but I can look at the technical aspects
08:18:53 <mnasiadka> #link https://blog.pypi.org/posts/2025-01-30-archival/
08:19:02 <mnasiadka> This looks like something new this year in pypi
08:19:29 <gtema> I personally like very much when projects on github are explicitly marked archived
08:19:30 <mnasiadka> tonyb: thanks
08:19:37 <gtema> it gives a clear signal - keep away
08:19:56 <mnasiadka> I’m not sure how different is retired vs archived in pypi
08:20:02 <mnasiadka> But that’s probably for tonyb to find out :)
08:20:20 <gtema> yeah
08:20:26 <tonyb> Hopefully is adds a banner like "this project is read-only" similar to github and others
08:20:33 <mnasiadka> That would be nice, I agree
08:20:48 <mnasiadka> Ok, that’s all of the AIs from last week
08:20:57 <mnasiadka> #topic Monasca Retirement
08:21:04 <mnasiadka> #link https://review.opendev.org/q/hashtag:%22monasca-retirement%22+(status:open%20OR%20status:merged)
08:21:12 <mnasiadka> The repository cleanup patches need to be merged. However, openstack/monasca-api and openstack/monasca-events-api are failing with zuul errors.
08:21:19 <mnasiadka> It's possible older stable and unmaintained branches need to be deleted too, to fix the cleanup on master. Need some help from the release team or TaCT SIG on how to proceed
08:21:30 <mnasiadka> That’s status from gouthamr
08:22:30 <mnasiadka> tonyb: It seems that the foundation member you mentioned hasn’t really acted - do you have any more information on that?
08:22:31 <tonyb> give me the AI I can look at it from a TaCT POV
08:22:40 <gtema> it upsets me how a single item can hold the whole community for 4-5 month now already? Just kill it and let people move forward, why are we taking so long on making an action
08:23:19 <gtema> sorry, this was rhetoric
08:23:21 <mnasiadka> gtema: I agree the time to do it was long time ago, so let’s at least not stall it this time - I’ll try to help gouthamr in progressing that
08:23:24 <mnasiadka> tonyb: AI granted :)
08:23:27 <tonyb> mnasiadka: It looks like *if* they're going to use it it wont be for 12months
08:23:57 <mnasiadka> Ah, *if*, then I don’t think we should really still wait.
08:24:26 <mnasiadka> Ok then, going forward
08:24:31 <mnasiadka> #topic TC Tracker, PTG Follow up
08:24:42 <mnasiadka> #link https://etherpad.opendev.org/p/tc-2026.1-tracker (Technical Committee activity tracker - 2026.1)
08:25:10 <tonyb> Yup I thought we'd agreed to retire monasca I'm sorry if I was holding things up by mistake
08:25:32 <noonedeadpunk> oops
08:25:46 * noonedeadpunk completely forgot about morning one
08:25:56 <mnasiadka> There’s the OpenStack Survey improvements topic there - I feel we should try to work for the data (that usually come from manual analysis) to be visible in a more dynamic way (maybe on the user survey webpage or something similar)
08:26:22 <mnasiadka> The deadline for submitting questions to survey is 1st Dec 2025 - for these that are interested
08:27:07 <mnasiadka> There’s also an etherpad with TC PTG summary
08:27:08 <mnasiadka> #link https://etherpad.opendev.org/p/oct2025-ptg-os-tc-summary
08:27:28 <mnasiadka> And a mail by gouthamr to the openstack-discuss ML
08:27:29 <mnasiadka> #link https://lists.openstack.org/archives/list/openstack-discuss@lists.openstack.org/message/RX3MZE33GEDV5JDHORZKRUKVDP47UMLJ/
08:28:31 <mnasiadka> tonyb: looking at tracker L119 and L124 - seems you have some AI in there - although I don’t know what needs to be done
08:28:59 <tonyb> mnasiadka: I do, I just haven't done it
08:29:01 <mnasiadka> noonedeadpunk: no worries, no AIs on you (yet) ;-)
08:29:08 <mnasiadka> tonyb: thank you for the update :)
08:29:15 <tonyb> LOL
08:29:33 <mnasiadka> Ok then, to next topic
08:29:36 <mnasiadka> #topic Python PTI and test runner guidance
08:29:43 <mnasiadka> #link https://lists.openstack.org/archives/list/openstack-discuss@lists.openstack.org/thread/3V3CNPQLB77SKFVLZ6LXJ5NPNYWW4QFD/
08:29:51 <gtema> mdasiadka and noonedeadpunk: wrt PQC, I am supporting that to a certain extend and wanted to drop passlib (a completely dropped lib) from our requirements and noticed that it is now only used in the deployment toolings
08:29:51 <mnasiadka> (Request for guidance on improving Python PTI doc to include pytest for Horizon plugins testing)
08:30:34 <gtema> would you be open still getting rid of it? Well, it is not a question honestly - this must be done. Period.
08:31:13 <mnasiadka> gtema: Sure, happy to do it in Kolla-Ansible - can you maybe start an openstack-discuss ML thread pointing to the repositories using it and we could track it that way?
08:31:38 <gtema> https://opendev.org/openstack/-/code?q=passlib&search_mode=exact
08:31:54 <mnasiadka> #link https://codesearch.opendev.org/?q=passlib&i=nope&literal=nope&files=&excludeFiles=&repos=
08:32:10 <gtema> but sure, I can start the thread and prepare change dropping it from requrements
08:32:15 <noonedeadpunk> gtema: looking at codesearch, osa does not need it
08:32:54 <gtema> right, but who is openstack/openstack-ansible-ops?
08:33:06 <noonedeadpunk> but bifrost on other hand seems tro rely on it?
08:33:14 <tonyb> gtema: I think that the openstack-ansible SIG?
08:33:23 <gtema> and who nowadays owns openstack/deb-* repos
08:33:23 <noonedeadpunk> yeah, osa. but you can drop it and let it fail :)
08:33:37 <gtema> ah, ok
08:33:48 <noonedeadpunk> or well. I can clean it up later this week
08:34:05 <gtema> thanks.
08:34:13 <noonedeadpunk> I think openstack-ansible-ops is not actually following requirements framework anyway
08:34:25 <gtema> Sorry for the delayed message that broke the topic boundary
08:34:51 <noonedeadpunk> it's pile of operator tooling, half of which should be refactored or dropped at this point anyway
08:35:12 <mnasiadka> K-A only uses passlib[bcrypt] for generating passwords, we can surely use something else
08:35:17 <mnasiadka> gtema: any recommendations? ;-)
08:35:58 <noonedeadpunk> we use haslib I think
08:36:34 <gtema> bcrypt is what keystone uses by default, but today the modern recommendation is to use argon2
08:36:40 <noonedeadpunk> not sure if it's better
08:36:56 <gtema> hashlib is bad, you should be using salt based hashing. In germany this is a requirement on the governmental level
08:37:03 <gtema> #link https://argon2-cffi.readthedocs.io/en/stable/
08:37:12 <noonedeadpunk> salt hashing for random password generator?
08:37:16 <gtema> this is what people should be using today
08:37:29 <mnasiadka> Ok, I’ll have a look in argon2
08:37:44 <gtema> whenever you store password hash in the DB it must be salt based hashing
08:37:46 <noonedeadpunk> can you supply a salted password to keystone when creating a service user?
08:38:07 <gtema> not the salted password - the salted hash of the password
08:39:17 <noonedeadpunk> but how you'd call openstack.cloud.identity_user with that?
08:39:25 <gtema> bcrypt is still safe, but argon is more future proof
08:39:54 <noonedeadpunk> or, `openstack user create`?
08:40:15 <gtema> noonedeadpunk - nothing changes on the password logic itself, only when you store the hash in the DB you should be applying salt to it - it has nothing to do with ansible modules for openstack
08:40:40 <noonedeadpunk> yes, but there's no database. And for storage it's supposed that Ansible Vault will be used
08:41:09 <noonedeadpunk> But you need to generate passwords in more or less plain text so that they could be supplied to services to create db/keystone/rabbitmq/etc users
08:41:28 <noonedeadpunk> so in context of deployment tools salting is irrelevant I'd assume
08:41:39 <tonyb> ... Can we move this to after the meeting.  It's valuable but also a tangent.
08:41:45 <noonedeadpunk> ++
08:41:48 <gtema> here there is nothing what we can do so far - those passwords stay in plain text in config files
08:42:15 <mnasiadka> Ok, let’s move it after meeting
08:42:27 <mnasiadka> And get back to the original topic - pytest for Horizon plugins
08:42:28 <noonedeadpunk> mnasiadka: fwiw https://opendev.org/openstack/openstack-ansible/src/branch/master/scripts/pw-token-gen.py - the thing we have
08:42:55 <gtema> wrt pti I would like to recall the discuss thread of Clark - we should establish a platform for reviewing old rules
08:43:16 <gtema> I think I have expressed my opinion in multiple threads clear enough
08:43:25 * noonedeadpunk need to get time to finally respond to these threads
08:44:03 <gtema> and the horizon folks themselves made a summary of the discussions to clarify their next steps
08:45:00 <mnasiadka> I agree with gtema - but I think this needs more people than 4 on a TC meeting - especially that noonedeadpunk is not up to date with the thread
08:45:20 <gtema> sure
08:45:29 <noonedeadpunk> I read it, I just never managed to respond as so many things to cover....
08:45:40 <mnasiadka> Ok, I’ll leave that for the next meeting
08:45:48 <mnasiadka> To the next topic...
08:45:55 <mnasiadka> #topic oslo.wsgi
08:46:02 <mnasiadka> #link https://lists.openstack.org/archives/list/openstack-discuss@lists.openstack.org/thread/IW2ZMYXGZQFPSLJRVT5OKFFX7XRGM2FF/
08:46:33 <gtema> not sure what is expected to be discussed here
08:46:36 <mnasiadka> TL;DR - there’s a proposal to create oslo.wsgi - all of the information is in the thread
08:46:57 <gtema> go for it, but do not make it a MUST
08:46:57 <noonedeadpunk> I think there was a general agreement that it's a good idea?
08:46:59 <tonyb> I feel like that's squarely in the oslo teams perview
08:47:15 <mnasiadka> tonyb: ++
08:48:05 <tonyb> We can reply with "match the import and governance patches" which is all I can see as being missing?
08:48:19 <mnasiadka> So I guess there’s nothing to discuss, the thread replies from Oslo team and others indicate it’s a good idea - so I assume the requestor will follow up with governance patches
08:48:39 <mnasiadka> Moving forward
08:48:46 <mnasiadka> #topic A check on gate health
08:48:58 <mnasiadka> Is there anything worth mentioning?
08:49:22 <tonyb> I can't think of anything.
08:49:42 <tonyb> gerrit and gitea have been updated in the last week
08:49:52 <tonyb> but they both went well
08:50:31 <mnasiadka> Ok then, happy to hear that
08:50:34 <mnasiadka> #topic Open Discussion and Reviews
08:50:35 <tonyb> We (infra-root) "discovered" a cool new zuul feature in the process
08:51:15 <tonyb> I don't have anything for Open Discussion
08:51:17 <gtema> which is it?
08:51:20 <mnasiadka> tonyb: cool? Which is?
08:52:07 <tonyb> gtema: You can pause the scheduler, so that if gerrit is unavailable it wont trigger a merge failure and then force those commits to be re-tested
08:52:20 <noonedeadpunk> oh, nice
08:52:58 <tonyb> It helps in a very narrow window but when it does it saves hours of "recheck"
08:53:08 <gtema> I haven't had merge failures often. It is usually a regular timeouts recheck madness
08:53:27 <mnasiadka> tonyb: ah, that’s what happened with my patch when it was “ready to submit” during some Zuul restart window ;-)
08:53:32 <noonedeadpunk> when you restart gerrit or upgrade gerrit - that really helpful indeed
08:53:47 <tonyb> Yeah this is really for when gerrit is down/unavailable
08:54:15 <tonyb> mnasiadka: That's different but similar
08:54:24 <mnasiadka> ack
08:54:40 <mnasiadka> Ok then, I see no open discussion topics
08:55:02 <mnasiadka> Thank you all for attending, see you next week in the regular timeslot
08:55:04 <mnasiadka> #endmeeting