Tuesday, 2025-09-16

opendevreviewOpenStack Proposal Bot proposed openstack/openstack-manuals master: Imported Translations from Zanata  https://review.opendev.org/c/openstack/openstack-manuals/+/94718004:40
*** jbernard_ is now known as jbernadr13:12
*** jbernadr is now known as jbernard_13:12
*** diablo_rojo_phone is now known as Guest2664313:12
*** jbernard_ is now known as jbernard13:40
*** clarkb is now known as Guest2667313:57
*** Sai__ is now known as Sai14:00
bauzasgouthamr: reminder that I won't again be able to attend today's meeting due to conflicting appointment :(14:16
gouthamrack bauzas14:36
*** Guest26673 is now known as clarkb14:46
*** logan_ is now known as Guest2669416:05
* gouthamr forgot to remind folks here about the meeting16:51
gouthamrthe irony16:51
gouthamrtc-members: we'll be catching up here in ~8 minutes for our weekly meeting16:52
gouthamr#startmeeting tc17:00
opendevmeetMeeting 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
opendevmeetUseful Commands: #action #agreed #help #info #idea #link #topic #startvote.17:00
opendevmeetThe meeting name has been set to 'tc'17:00
gouthamrWelcome 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
gouthamrToday's meeting agenda can be found at https://wiki.openstack.org/wiki/Meetings/TechnicalCommittee17:00
gouthamr#topic Roll Call17:00
cardoeo/17:01
noonedeadpunko/17:01
mnasiadkao/17:01
spotz[m]o/17:02
gouthamrcourtesy-ping: frickler, gtema, jbernard17:03
frickler\o17:03
gtemao/17:03
gouthamrnoted absence: b a u z a s, g m a a n17:03
gouthamr that's everyone 17:04
gouthamrlets get started17:04
gouthamr#topic Last Week's AIs17:04
gouthamrwe'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 openstack17:05
gouthamrthe 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:06
gouthamri had a chat with TheJulia if this would be appropriate to surface to the OpenInfra Board17:07
gouthamrhowever, we decided on first getting this on openstack-discuss because we might need some help from the foundation staff.. 17:07
gouthamra 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-discuss17:08
gouthamran 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:08
* gouthamr hopes that doesn't sound too alarming - is only re-capping parts that seemed like action items :) 17:09
gouthamr noonedeadpunk and seunghunlee added findings on the default charset/collation issue here:17:10
gouthamr#link https://etherpad.opendev.org/p/gazpacho-collations-charsets17:10
gouthamr^ noonedeadpunk what would be the next steps here?17:10
noonedeadpunkso I've started collecting data on projects and if they do have charset defined in migrations17:11
noonedeadpunkit seems so far that only core projects were doing that, but not all17:12
gouthamr"core projects?"17:12
noonedeadpunkwith that I think we need to come up with some kind of "community" goal to align that17:12
gouthamrack17:12
noonedeadpunkeh, keystone, glance, nova, neutron, cinder17:12
noonedeadpunklike - the most used ones :)17:13
noonedeadpunkthe 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 projects17:14
noonedeadpunkand then provide projects with recommendations on what they ideally should be using17:14
noonedeadpunkand leverage all kind of changes through migrations17:15
noonedeadpunkat least this how I see next steps there17:15
clarkbas a user I think some consistency is a good thing17:16
clarkbwe probably won't have universal consistency due to postgres (and potentially other dbs existing) but it is always nice when behaviors don't differ unnecessarily17:16
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 projects17:17
noonedeadpunkwe don't even know if postgres does work, or intend to work17:17
gouthamryeah, nope - we've killed all jobs and said there's no testing 17:17
* noonedeadpunk recalls some ml on the topic of postgres17:17
clarkbok then its mariadb vs mysql17:18
gouthamr#link https://governance.openstack.org/tc/resolutions/20170613-postgresql-status.html 17:18
clarkbbasically 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 users17:18
gouthamr"MySQL family of databases only" 17:18
noonedeadpunkvs percona? :)17:18
noonedeadpunkyeah17:18
gouthamrack, ty for all the information gathering, noonedeadpunk - and for framing the plan17:19
gouthamrwe can catch up on this again next week17:19
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 type17:20
noonedeadpunkYeah, 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 do17:20
gouthamrack17:21
mnasiadkaI 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/MySQL17:21
* gouthamr deja vu - feels like we've had this discussion in the past17:22
noonedeadpunkin osa we tend to test both in-distro (for distro packaged jobs) and also tend to stick with latest LTS indeed17:22
noonedeadpunkbut it would quite postpone adding devstack jobs for distros17:23
noonedeadpunkas it takess a while and a next release of mariadb to add support for new versions17:23
noonedeadpunkso it could be like 3 month after ubuntu LTS being released to mariadb building packages17:23
noonedeadpunkand it was over half a year for CentOS 1017:24
mnasiadkaWell, I rather mentioned MariaDB LTS - of course they tend to be late building packages for new distribution versions - but it is what it is17:24
mnasiadkaAnd CentOS 10/Rocky 10/Alma 10 usability in OpenStack land is a bit... problematic17:25
mnasiadkaSo I wouldn't worry that much ;-)17:25
noonedeadpunkI'm not sure if it's same level problematic for devstack...17:25
mnasiadkaAs in I wanted to say that it's still problematic, given some missing packages and other things17:25
noonedeadpunkbut I don't know that for sure17:25
* noonedeadpunk used devstack too little17:25
mnasiadkathere's now a Rocky 10 devstack platform job, but from what I understand there's not a lot of coverage in there17:26
spotz[m]If a bug were opened for CentOS Stream 10 I would have something to work with...17:26
mnasiadkaprobably switching tempest to use centos10/rocky10 instead of 9 would give us more, but it's probably a discussion for a different meeting17:26
noonedeadpunkit's not a centos fault I'm discussing, more an ecosystem issue around all EL lately17:27
mnasiadkaI can only complain on EPEL and packages that have been removed in EL10 compared to EL9 - but we'll handle that eventually17:27
fricklerthis is getting a bit offtopic, isn't it?17:28
gouthamryes17:28
mnasiadkaYes, wanted to say let's get back to databases :)17:28
spotz[m]my specialty:)17:28
gouthamrsorry, it looks like we have a desire to get mariadb latest tested, and also test with CS10/RockyLinux10 (Alma? :) ) tested with projects' devstack based jobs17:29
gouthamrgood recommendation - a separate topic, and one probably for the PTG17:29
mnasiadka+117:29
gouthamr(agreed that deployment projects shouldn't be the first ones to find these bugs)17:30
gouthamralright, lets move to the next AI: 17:30
gouthamrnext steps on leaderless teams:17:30
gouthamrhttps://etherpad.opendev.org/p/2026.1-leaderless17:30
gouthamrwe have waited about ~10 days, and there've been no PTL volunteers for venus, openstack-charms and vitrage17:31
* noonedeadpunk thinks it fine for deployment projects to find these bugs first17:31
* noonedeadpunk used to finding some bugs around even openstack dependencies over years17:32
fricklerso shall we move these projects to inactive?17:32
mnasiadkaI guess we have no other choice17:33
frickleralso no action from the claimed monasca maintainer, looks like only hot air to me, too17:33
gouthamri could bump the threads again and suggest the next steps:17:33
gouthamrit 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
gouthamrVitrage and OpenStack Charms have had contributions - we should check if they prefer to use DPL, or be handed off into a SIG17:33
noonedeadpunkI can potentially pick vitrage... Though capacity wise it's being tough...17:34
spotz[m]Should we check and see if charms is even needed any longer with Sunbeam?17:34
gouthamri think they told us that the stable version is still being used/maintained17:35
fricklerspotz[m]: I tried to contact people in the sunbeam channel, but no response there17:35
spotz[m]Ok17:35
fungimaybe both are effectively inactive?17:35
gouthamrwhich both?17:36
fricklersunbeam + charms?17:36
fungiboth charms and sunbeam were primarily under maintenance by the same organization17:36
gouthamr#link https://review.opendev.org/q/project:%5E.*charms* 17:36
gouthamr#link https://review.opendev.org/q/project:%5Eopenstack/charm.* 17:37
gouthamrneither are "inactive"17:37
spotz[m]Yeah and at first we questioned if they should be the same project if remembering correctly, it's been a while17:37
gouthamr(we have a PTL for sunbeam too)17:37
spotz[m]That's why I suggested asking them:)17:38
fungiso maybe they just don't use their irc channels in that case17:38
fungior read posts to the mailing list17:38
fricklerwhich might imply they would work better outside of OpenStack governance?17:39
gouthamr+117:39
gouthamri agree, getting conformance seems like a wild goose chase that i'm not a fan of17:40
noonedeadpunkthis reminds me about tripleO now17:40
mnasiadkaSunbeam PTL seems to be active, at least he attended some recent Magnum weekly meetings and was actively working on patches17:40
mnasiadkaBut Charms might be similar to TripleO17:41
noonedeadpunkwe just had a very weird times with TripleO deprecation/retirement17:41
gouthamrnoonedeadpunk: 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:41
noonedeadpunkno, not about inactive state, but about what mess it was when they wanted to maintain only specific unmaintained branch, but then not mainatained ones17:42
gouthamryeah17:42
noonedeadpunkdespite being branched and released for them17:42
noonedeadpunk(and as well being a single-company product/project)17:42
gouthamrany further thoughts here besides the ML updates that are necessary?17:43
gouthamrthe last AI was taken after the meeting17:44
gouthamrwe discussed testing with AlmaLinux over the past week17:44
gouthamrthere was a need for a volunteer familiar with the OpenStack ecosystem.. and there was a suggestion to run the effort as a pop up team17:45
gouthamrwould anyone on the TC be interested to take this on?17:45
noonedeadpunkI can help out where applicable, but won't stand up for taking the lead17:47
* noonedeadpunk doesn't run any EL-like system in production17:47
gouthamrthanks noonedeadpunk that's appreciated.. i think we've heard similar sentiments from others.. 17:48
gouthamrif 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 again17:49
gouthamrthat's a wrap on all the ongoing items 17:50
gouthamri'll go out-of-order on the agenda today because we will be pressed for time17:50
gouthamr#topic PTG Scheduling 17:50
gouthamr#link https://lists.openstack.org/archives/list/openstack-discuss@lists.openstack.org/thread/B6QU75BPCKBDURPF6UW4K6JWUQ3NKFJJ/17:50
gouthamrthe next thing diablo_rojo/foundation staff helping us run the PTG would do: send out a reminder to schedule slots17:51
gouthamri was reminded that we had some thoughts last time to dedicate time for cross project discussions17:51
Guest26643Correct. I will likely get the sign up out early next week. I was going to send the list of confirmed teams out this week17:51
Guest26643Ughh nick got me again. 17:51
gouthamrhey Guest 2664217:51
gouthamrhey Guest 26643*17:52
gouthamr:P17:52
*** Guest26643 is now known as diablo_rojo_phone17:52
gouthamrdo you think the TC could recommend it formally?17:52
diablo_rojo_phoneFixed. 17:52
gouthamrdiablo_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
diablo_rojo_phoneLike to be included as a part of the sign up kickoff email? 17:53
JayFCross-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
diablo_rojo_phoneI can definitely make that recommendation. 17:53
diablo_rojo_phoneWe have done it in the past so there is definitely precedent. 17:53
clarkbthe database char type and collation selection would make a good topic17:54
gouthamrand personally, i want to let project teams know that its not okay to book all five western hemisphere slots all five days of the week17:54
clarkbeventlet removal too potentially17:54
gouthamr+117:54
gouthamri'll throw in the TC+project maintainers discussion too, so we can put sundry/governance topics there that don't fit anywhere else17:56
gouthamri'll share the etherpad here so we can plan topics for the TC discussions17:57
gouthamrthat's all i had for $topic17:57
gouthamranything else to note?17:57
gouthamr#topic A check on gate health17:58
mnasiadkaThe 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
gouthamroh, will try that mnasiadka 17:58
gouthamrany gate concerns to note this week?17:58
gouthamrwe're past the RC deadline, i hope things were minimally bumpy 17:59
gouthamrokay, we're at the hour18:00
gouthamranything to note for the minutes?18:00
clarkbtkajinam is asking for clarification to vendor ply into yaql18:00
clarkbthere is an email on the mailing lsit about it18:00
fungi#link https://lists.openstack.org/archives/list/openstack-discuss@lists.openstack.org/thread/PKWNZ7QL6PRJI2WXMMWYYZYWYZA3Z7E4 Status of ply18:00
gouthamr"Looking at the code, it seems all codes are tagged with BSD 3-clause license[3]18:01
gouthamrthough the repository lacks the LICENSE file."18:01
fungitagged it specifically for tc-members feedback18:01
tkajinamo/18:01
fungiyeah, the relevant files have bsd-3 licenses included in code comments, which should be sufficient18:02
fungii 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 spot18:03
gtemai would prefer not reimplementing the wheel - makes no sense from my pov, so vendor it18:03
gouthamr+1, if we have no legal issues of adding BSD-3 code to our codebase that's apachev2 licensed18:04
fungi"The list of acceptable licenses includes ASLv2, BSD (both forms), MIT, PSF, LGPL, ISC, and MPL."18:05
fungi#link https://governance.openstack.org/tc/reference/licensing.html Licensing requirements18:05
fungi"OpenStack projects and libraries ... BSD 2-Clause and 3-Clause licenses meet this requirement."18:06
fungialso18:06
gouthamrty that's a good clarification18:06
fungibasically the tc has already declared that's fine18:06
gouthamrso would this mean that the code will go to both mistral and heat? or someplace else - oslo?18:07
clarkbI think into yaql18:07
tkajinamgouthamr, my plan was to import the ply code into yaql as its private module18:07
gouthamrAH, ack18:08
gouthamrthat sounds like a good plan to18:08
tkajinamso that no change is needed in heat or mistral18:08
gouthamr++18:08
gouthamri can respond on the ML thread18:09
gouthamrlets close the meeting here, but we can continue discussing this if required18:09
gouthamrthank you all for attending18:09
gouthamr#endmeeting18:09
opendevmeetMeeting ended Tue Sep 16 18:09:53 2025 UTC.  Information about MeetBot at http://wiki.debian.org/MeetBot . (v 0.1.4)18:09
opendevmeetMinutes:        https://meetings.opendev.org/meetings/tc/2025/tc.2025-09-16-17.00.html18:09
opendevmeetMinutes (text): https://meetings.opendev.org/meetings/tc/2025/tc.2025-09-16-17.00.txt18:09
opendevmeetLog:            https://meetings.opendev.org/meetings/tc/2025/tc.2025-09-16-17.00.log.html18:09
spotz[m]Thanks all18:12

Generated by irclog2html.py 4.0.0 by Marius Gedminas - find it at https://mg.pov.lt/irclog2html/!