17:00:20 <gouthamr> #startmeeting tc
17:00:20 <opendevmeet> Meeting started Tue Sep 16 17:00:20 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:20 <opendevmeet> Useful Commands: #action #agreed #help #info #idea #link #topic #startvote.
17:00:20 <opendevmeet> The meeting name has been set to 'tc'
17:00:27 <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:30 <gouthamr> Today's meeting agenda can be found at https://wiki.openstack.org/wiki/Meetings/TechnicalCommittee
17:00:34 <gouthamr> #topic Roll Call
17:01:10 <cardoe> o/
17:01:12 <noonedeadpunk> o/
17:01:23 <mnasiadka> o/
17:02:53 <spotz[m]> o/
17:03:00 <gouthamr> courtesy-ping: frickler, gtema, jbernard
17:03:09 <frickler> \o
17:03:09 <gtema> o/
17:03:10 <gouthamr> noted absence: b a u z a s, g m a a n
17:04:21 <gouthamr> that's everyone
17:04:25 <gouthamr> lets get started
17:04:28 <gouthamr> #topic Last Week's AIs
17:05:24 <gouthamr> we're past the RC1 deadline, so some action items may come back - but, i'll still hold the one on the resolution with guidelines for phone-home from openstack
17:06:43 <gouthamr> the ongoing elections will wrap up at 2345 UTC on September 17th 2025.. we had an AI follow up with issues that affected this election..
17:07:35 <gouthamr> i had a chat with TheJulia if this would be appropriate to surface to the OpenInfra Board
17:07:59 <gouthamr> however, we decided on first getting this on openstack-discuss because we might need some help from the foundation staff..
17:08:06 <gouthamr> a lot of discussion happened here and on #openstack-election - i'll take an AI to compile that information and start a mail thread on openstack-discuss
17:08:52 <gouthamr> an outcome of that discussion can inform us if we need to approach the foundation legal counsel for any changes we'll want to make to the electorate itself as it was suggested last week
17:09:18 * gouthamr hopes that doesn't sound too alarming - is only re-capping parts that seemed like action items :)
17:10:07 <gouthamr> noonedeadpunk and seunghunlee added findings on the default charset/collation issue here:
17:10:07 <gouthamr> #link https://etherpad.opendev.org/p/gazpacho-collations-charsets
17:10:37 <gouthamr> ^ noonedeadpunk what would be the next steps here?
17:11:56 <noonedeadpunk> so I've started collecting data on projects and if they do have charset defined in migrations
17:12:12 <noonedeadpunk> it seems so far that only core projects were doing that, but not all
17:12:25 <gouthamr> "core projects?"
17:12:32 <noonedeadpunk> with that I think we need to come up with some kind of "community" goal to align that
17:12:49 <gouthamr> ack
17:12:50 <noonedeadpunk> eh, keystone, glance, nova, neutron, cinder
17:13:01 <noonedeadpunk> like - the most used ones :)
17:14:01 <noonedeadpunk> the question what this goal it should be... offload responsibility to operators to check and care about charsets/collations or take this repsonsibility consistently across all projects
17:14:51 <noonedeadpunk> and then provide projects with recommendations on what they ideally should be using
17:15:03 <noonedeadpunk> and leverage all kind of changes through migrations
17:15:14 <noonedeadpunk> at least this how I see next steps there
17:16:15 <clarkb> as a user I think some consistency is a good thing
17:16:45 <clarkb> we probably won't have universal consistency due to postgres (and potentially other dbs existing) but it is always nice when behaviors don't differ unnecessarily
17:17:34 <gouthamr> +1, and if a bunch of operators will all have to take the same pain, it makes sense for us to ship this with the projects and have a guideline for future database usage within the projects
17:17:37 <noonedeadpunk> we don't even know if postgres does work, or intend to work
17:17:59 <gouthamr> yeah, nope - we've killed all jobs and said there's no testing
17:17:59 * noonedeadpunk recalls some ml on the topic of postgres
17:18:06 <clarkb> ok then its mariadb vs mysql
17:18:26 <gouthamr> #link https://governance.openstack.org/tc/resolutions/20170613-postgresql-status.html
17:18:37 <clarkb> basically there is still enough choice here between implementations and versions that we probably can't expect a complete solution but where it makes sense I think consistency is good for users
17:18:44 <gouthamr> "MySQL family of databases only"
17:18:45 <noonedeadpunk> vs percona? :)
17:18:51 <noonedeadpunk> yeah
17:19:38 <gouthamr> ack, ty for all the information gathering, noonedeadpunk - and for framing the plan
17:19:45 <gouthamr> we can catch up on this again next week
17:20:00 <spotz[m]> I think it's fine as long as it's a DB using the mysql style authentication and table structure vs postgres/Oracle type
17:20:38 <noonedeadpunk> Yeah, I'll totally finish with the project list by EOD, and then we can discuss details and form some kind of base for what we want to do
17:21:07 <gouthamr> ack
17:21:18 <mnasiadka> I think the plan should also include testing on latest LTS of MariaDB (because most probably that's what users are using, judging by what the deployment projects are using today), probably something similar on MySQL front - because currently devstack uses what is in-distro - and that's usually a bit old MariaDB/MySQL
17:22:22 * gouthamr deja vu - feels like we've had this discussion in the past
17:22:40 <noonedeadpunk> in osa we tend to test both in-distro (for distro packaged jobs) and also tend to stick with latest LTS indeed
17:23:08 <noonedeadpunk> but it would quite postpone adding devstack jobs for distros
17:23:30 <noonedeadpunk> as it takess a while and a next release of mariadb to add support for new versions
17:23:56 <noonedeadpunk> so it could be like 3 month after ubuntu LTS being released to mariadb building packages
17:24:20 <noonedeadpunk> and it was over half a year for CentOS 10
17:24:41 <mnasiadka> Well, I rather mentioned MariaDB LTS - of course they tend to be late building packages for new distribution versions - but it is what it is
17:25:04 <mnasiadka> And CentOS 10/Rocky 10/Alma 10 usability in OpenStack land is a bit... problematic
17:25:11 <mnasiadka> So I wouldn't worry that much ;-)
17:25:31 <noonedeadpunk> I'm not sure if it's same level problematic for devstack...
17:25:34 <mnasiadka> As in I wanted to say that it's still problematic, given some missing packages and other things
17:25:38 <noonedeadpunk> but I don't know that for sure
17:25:52 * noonedeadpunk used devstack too little
17:26:16 <mnasiadka> there's now a Rocky 10 devstack platform job, but from what I understand there's not a lot of coverage in there
17:26:23 <spotz[m]> If a bug were opened for CentOS Stream 10 I would have something to work with...
17:26:43 <mnasiadka> probably switching tempest to use centos10/rocky10 instead of 9 would give us more, but it's probably a discussion for a different meeting
17:27:06 <noonedeadpunk> it's not a centos fault I'm discussing, more an ecosystem issue around all EL lately
17:27:50 <mnasiadka> I can only complain on EPEL and packages that have been removed in EL10 compared to EL9 - but we'll handle that eventually
17:28:13 <frickler> this is getting a bit offtopic, isn't it?
17:28:18 <gouthamr> yes
17:28:26 <mnasiadka> Yes, wanted to say let's get back to databases :)
17:28:28 <spotz[m]> my specialty:)
17:29:07 <gouthamr> sorry, it looks like we have a desire to get mariadb latest tested, and also test with CS10/RockyLinux10 (Alma? :) ) tested with projects' devstack based jobs
17:29:31 <gouthamr> good recommendation - a separate topic, and one probably for the PTG
17:29:39 <mnasiadka> +1
17:30:02 <gouthamr> (agreed that deployment projects shouldn't be the first ones to find these bugs)
17:30:36 <gouthamr> alright, lets move to the next AI:
17:30:36 <gouthamr> next steps on leaderless teams:
17:30:36 <gouthamr> https://etherpad.opendev.org/p/2026.1-leaderless
17:31:09 <gouthamr> we have waited about ~10 days, and there've been no PTL volunteers for venus, openstack-charms and vitrage
17:31:34 * noonedeadpunk thinks it fine for deployment projects to find these bugs first
17:32:18 * noonedeadpunk used to finding some bugs around even openstack dependencies over years
17:32:55 <frickler> so shall we move these projects to inactive?
17:33:08 <mnasiadka> I guess we have no other choice
17:33:37 <frickler> also no action from the claimed monasca maintainer, looks like only hot air to me, too
17:33:39 <gouthamr> i could bump the threads again and suggest the next steps:
17:33:39 <gouthamr> it does look like activity has slowed down in venus, we could propose its retirement in G if there are no volunteers to maintain the project.
17:33:39 <gouthamr> Vitrage and OpenStack Charms have had contributions - we should check if they prefer to use DPL, or be handed off into a SIG
17:34:04 <noonedeadpunk> I can potentially pick vitrage... Though capacity wise it's being tough...
17:34:45 <spotz[m]> Should we check and see if charms is even needed any longer with Sunbeam?
17:35:03 <gouthamr> i think they told us that the stable version is still being used/maintained
17:35:11 <frickler> spotz[m]: I tried to contact people in the sunbeam channel, but no response there
17:35:23 <spotz[m]> Ok
17:35:56 <fungi> maybe both are effectively inactive?
17:36:11 <gouthamr> which both?
17:36:37 <frickler> sunbeam + charms?
17:36:45 <fungi> both charms and sunbeam were primarily under maintenance by the same organization
17:36:55 <gouthamr> #link https://review.opendev.org/q/project:%5E.*charms*
17:37:13 <gouthamr> #link https://review.opendev.org/q/project:%5Eopenstack/charm.*
17:37:19 <gouthamr> neither are "inactive"
17:37:24 <spotz[m]> Yeah and at first we questioned if they should be the same project if remembering correctly, it's been a while
17:37:38 <gouthamr> (we have a PTL for sunbeam too)
17:38:15 <spotz[m]> That's why I suggested asking them:)
17:38:23 <fungi> so maybe they just don't use their irc channels in that case
17:38:45 <fungi> or read posts to the mailing list
17:39:08 <frickler> which might imply they would work better outside of OpenStack governance?
17:39:44 <gouthamr> +1
17:40:23 <gouthamr> i agree, getting conformance seems like a wild goose chase that i'm not a fan of
17:40:25 <noonedeadpunk> this reminds me about tripleO now
17:40:55 <mnasiadka> Sunbeam PTL seems to be active, at least he attended some recent Magnum weekly meetings and was actively working on patches
17:41:03 <mnasiadka> But Charms might be similar to TripleO
17:41:31 <noonedeadpunk> we just had a very weird times with TripleO deprecation/retirement
17:41:37 <gouthamr> noonedeadpunk: in the way that it is inactive? tripleo is retired for good as far as we're concerned.. its maintenance doesn't happen on opendev.org
17:42:23 <noonedeadpunk> no, not about inactive state, but about what mess it was when they wanted to maintain only specific unmaintained branch, but then not mainatained ones
17:42:32 <gouthamr> yeah
17:42:32 <noonedeadpunk> despite being branched and released for them
17:42:53 <noonedeadpunk> (and as well being a single-company product/project)
17:43:25 <gouthamr> any further thoughts here besides the ML updates that are necessary?
17:44:02 <gouthamr> the last AI was taken after the meeting
17:44:23 <gouthamr> we discussed testing with AlmaLinux over the past week
17:45:17 <gouthamr> there was a need for a volunteer familiar with the OpenStack ecosystem.. and there was a suggestion to run the effort as a pop up team
17:45:39 <gouthamr> would anyone on the TC be interested to take this on?
17:47:23 <noonedeadpunk> I can help out where applicable, but won't stand up for taking the lead
17:47:43 * noonedeadpunk doesn't run any EL-like system in production
17:48:11 <gouthamr> thanks noonedeadpunk that's appreciated.. i think we've heard similar sentiments from others..
17:49:20 <gouthamr> if this is interesting to anyone, it'll be helpful for a lot of reasons as detailed over the past week.. i'll mention this to the ML again
17:50:23 <gouthamr> that's a wrap on all the ongoing items
17:50:27 <gouthamr> i'll go out-of-order on the agenda today because we will be pressed for time
17:50:32 <gouthamr> #topic PTG Scheduling
17:50:36 <gouthamr> #link https://lists.openstack.org/archives/list/openstack-discuss@lists.openstack.org/thread/B6QU75BPCKBDURPF6UW4K6JWUQ3NKFJJ/
17:51:10 <gouthamr> the next thing diablo_rojo/foundation staff helping us run the PTG would do: send out a reminder to schedule slots
17:51:33 <gouthamr> i was reminded that we had some thoughts last time to dedicate time for cross project discussions
17:51:48 <Guest26643> Correct. I will likely get the sign up out early next week. I was going to send the list of confirmed teams out this week
17:51:58 <Guest26643> Ughh nick got me again.
17:51:59 <gouthamr> hey Guest 26642
17:52:04 <gouthamr> hey Guest 26643*
17:52:04 <gouthamr> :P
17:52:14 <gouthamr> do you think the TC could recommend it formally?
17:52:39 <diablo_rojo_phone> Fixed.
17:53:20 <gouthamr> diablo_rojo_phone: we wanted project teams to prioritize cross project discussions and set the agendas for this on Oct 27,28 (i.e., first two days of the PTG)
17:53:20 <diablo_rojo_phone> Like to be included as a part of the sign up kickoff email?
17:53:28 <JayF> Cross-project discussions are nice in general; but IME the most successful ones have been centered around a specific issue, or specific projects with an interface point.
17:53:35 <diablo_rojo_phone> I can definitely make that recommendation.
17:53:46 <diablo_rojo_phone> We have done it in the past so there is definitely precedent.
17:54:35 <clarkb> the database char type and collation selection would make a good topic
17:54:35 <gouthamr> and personally, i want to let project teams know that its not okay to book all five western hemisphere slots all five days of the week
17:54:39 <clarkb> eventlet removal too potentially
17:54:42 <gouthamr> +1
17:56:00 <gouthamr> i'll throw in the TC+project maintainers discussion too, so we can put sundry/governance topics there that don't fit anywhere else
17:57:10 <gouthamr> i'll share the etherpad here so we can plan topics for the TC discussions
17:57:40 <gouthamr> that's all i had for $topic
17:57:44 <gouthamr> anything else to note?
17:58:22 <gouthamr> #topic A check on gate health
17:58:26 <mnasiadka> The TC+project maintainers session could be scheduled before call to schedule all $project PTG slots - I always end up having Kolla PTG slots at the time of that session ;-)
17:58:51 <gouthamr> oh, will try that mnasiadka
17:58:58 <gouthamr> any gate concerns to note this week?
17:59:32 <gouthamr> we're past the RC deadline, i hope things were minimally bumpy
18:00:25 <gouthamr> okay, we're at the hour
18:00:32 <gouthamr> anything to note for the minutes?
18:00:40 <clarkb> tkajinam is asking for clarification to vendor ply into yaql
18:00:46 <clarkb> there is an email on the mailing lsit about it
18:00:53 <fungi> #link https://lists.openstack.org/archives/list/openstack-discuss@lists.openstack.org/thread/PKWNZ7QL6PRJI2WXMMWYYZYWYZA3Z7E4 Status of ply
18:01:26 <gouthamr> "Looking at the code, it seems all codes are tagged with BSD 3-clause license[3]
18:01:26 <gouthamr> though the repository lacks the LICENSE file."
18:01:27 <fungi> tagged it specifically for tc-members feedback
18:01:45 <tkajinam> o/
18:02:00 <fungi> yeah, the relevant files have bsd-3 licenses included in code comments, which should be sufficient
18:03:07 <fungi> i don't think it's the first time we've vendored one-or-two-file libraries into openstack projects, though i'd be hard pressed to provide a historical example on the spot
18:03:32 <gtema> i would prefer not reimplementing the wheel - makes no sense from my pov, so vendor it
18:04:20 <gouthamr> +1, if we have no legal issues of adding BSD-3 code to our codebase that's apachev2 licensed
18:05:11 <fungi> "The list of acceptable licenses includes ASLv2, BSD (both forms), MIT, PSF, LGPL, ISC, and MPL."
18:05:20 <fungi> #link https://governance.openstack.org/tc/reference/licensing.html Licensing requirements
18:06:13 <fungi> "OpenStack projects and libraries ... BSD 2-Clause and 3-Clause licenses meet this requirement."
18:06:15 <fungi> also
18:06:32 <gouthamr> ty that's a good clarification
18:06:42 <fungi> basically the tc has already declared that's fine
18:07:24 <gouthamr> so would this mean that the code will go to both mistral and heat? or someplace else - oslo?
18:07:41 <clarkb> I think into yaql
18:07:55 <tkajinam> gouthamr, my plan was to import the ply code into yaql as its private module
18:08:04 <gouthamr> AH, ack
18:08:14 <gouthamr> that sounds like a good plan to
18:08:18 <tkajinam> so that no change is needed in heat or mistral
18:08:20 <gouthamr> ++
18:09:27 <gouthamr> i can respond on the ML thread
18:09:48 <gouthamr> lets close the meeting here, but we can continue discussing this if required
18:09:51 <gouthamr> thank you all for attending
18:09:53 <gouthamr> #endmeeting