17:00:41 <gouthamr> #startmeeting tc
17:00:41 <opendevmeet> Meeting started Tue Jul 29 17:00:41 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:41 <opendevmeet> Useful Commands: #action #agreed #help #info #idea #link #topic #startvote.
17:00:41 <opendevmeet> The meeting name has been set to 'tc'
17:00:57 <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:01:01 <gouthamr> Today's meeting agenda can be found at https://wiki.openstack.org/wiki/Meetings/TechnicalCommittee
17:01:07 <gouthamr> #topic Roll Call
17:01:26 <spotz[m]> o/
17:01:28 <frickler> \o
17:02:38 <gouthamr> noted absence: n o o n e dead punk, m n a sia d k a
17:02:42 <gouthamr> courtesy-ping: gmaan, gtema, cardoe, bauzas
17:02:49 <bauzas> o/
17:02:49 <gmaan> o/
17:03:08 <bauzas> last meeting for me before my 3-week PTO period
17:03:11 <frickler> gouthamr: gtema wrote earlier about being away, too
17:03:23 <gouthamr> oh
17:03:27 <gouthamr> i missed that
17:03:54 <gouthamr> ty frickler
17:04:26 <gouthamr> bauzas: we'll help you pack :)
17:04:35 <bauzas> ;-)
17:05:12 <gouthamr> alright, lets get started..
17:05:12 <gouthamr> #topic Last Week's AIs
17:05:50 <gouthamr> we took an AI about a long pending patch to clarify affiliation
17:05:51 <spotz[m]> Oh and I’m out next week speaking of away:)
17:05:57 <gouthamr> ack spotz[m]
17:06:15 <gouthamr> #link https://review.opendev.org/c/openstack/governance/+/949432 (Require declaration of affiliation from TC Candidates)
17:06:37 <gouthamr> this needs to be updated to depend on
17:06:44 <gouthamr> #link https://review.opendev.org/c/openstack/governance/+/956024 (Define "affiliation" within the context of the TC)
17:07:00 <gouthamr> i'll do that.. but please do review
17:07:19 <gouthamr> spotz[m]: already noted that we can copy the bylaws' definition of this before it is taken down
17:07:50 <gmaan> I think that was more legal and might need legal chekcs?
17:08:07 <gouthamr> yeah its more or less the same in essence *i think*, but has more legalese
17:08:16 <gmaan> and that is why we wanted a simple one which can cover TC diversity things from organizational point of view
17:08:51 <gmaan> It will be helpful to keep it as simple as even it is not full
17:09:05 <gouthamr> i agree in spirit, think spotz[m] wanted to cover our bases in case someone challenged it
17:10:12 <gouthamr> she had a good point about subsidiaries - an example being Red Hat owned by IBM, except, i, as a Red Hat employee know that i'm not an IBM employee, but, how does the world perceive this?
17:10:22 <gmaan> that is the main point and challenge, if we want to have it to challenge then it is out of scope from TC as that might need legal checks
17:10:56 <gmaan> we consider those separate organization from TC perspective.
17:11:16 <gmaan> I mean we just need to define what we want from TC organizational diversity point of view
17:11:31 <gmaan> otherwise there are a lot of things- partner companies etc
17:11:39 <gouthamr> because they're separate OpenInfra Member companies?
17:12:18 <gmaan> I do not know :) that is why I am saying going in same way as it was in bylaw can have a lot of open questions
17:12:24 <fungi> note that there's no requirement for a tc member to be employed by a member company (or any company at all), so that sounds like it could be a questionable distinction
17:12:33 <gmaan> yeah
17:12:45 <gmaan> we should not consider membership here
17:12:47 <gouthamr> ah yes, i tried stating that in the first line of the change
17:12:54 <gmaan> ++
17:13:24 <bauzas> I haven't looked at the affiliation patches but I'll
17:13:40 <bauzas> I still have one open question about external people working on the behalf of a company
17:13:43 <gmaan> I will add comment there and we can discuss async
17:13:53 <bauzas> is it covered by the affiniliation definition patch ?
17:14:22 <gmaan> bauzas: those still consider as contractor/employee and should decalre their affiliation as the company they are contributing for
17:14:46 <bauzas> okay, that was my thought, just wanted to make sure we were clarifying that
17:14:49 <gouthamr> yes
17:14:51 <gouthamr> we are
17:14:56 <gmaan> ++
17:15:25 <bauzas> I'll shepherd the patches anyway
17:15:26 <gouthamr> tl;dr: we need a TC member to be an individual member of the OpenInfra Foundation, and they don't need to be affiliated.. but, if they are affiliated, we've the diversity requirement .. we got a question on what does it mean to be affiliated, that's being determined here: https://review.opendev.org/c/openstack/governance/+/956024
17:15:31 <gmaan> bcz there can be case where employee of CompanyA contributing on behalf of companyB with companyA and CompanyB contract
17:15:41 <gouthamr> ^ lets discuss more directly on the patch
17:15:54 <gmaan> we just need to make sure "declare your affiliation from contribution point of view"
17:16:39 <gmaan> rest other (subsidiary, contract etc ) are out of scope for us
17:16:48 <gmaan> gouthamr: ++ I will check and add comment there
17:16:54 <gouthamr> ty gmaan
17:17:06 <gouthamr> and others for reviewing!
17:17:10 <gouthamr> i also looped in folks that shared their opinion here, and TheJulia and jbryce.. lets hash this out :)
17:17:39 * TheJulia appears
17:18:04 <fungi> TheJulia: tl;dr, defining "affiliation" in https://review.opendev.org/949432
17:18:09 <gouthamr> haha, didn't mean to summon you, but, please do check the patch above when you have time TheJulia
17:18:29 <gouthamr> lets move to the next AI: Monasca (and inactive projects in general)..
17:18:53 <TheJulia> fungi: reading
17:18:57 <gouthamr> i've added this as a separate topic to cover what happened between meetings and what we'll do next
17:19:43 <gouthamr> we had an AI regarding a review dashboard, i suppose we'll table that to next week since no onedeadpunk isn't here.. no rush
17:19:49 <spotz[m]> Fand I’m laggy
17:20:11 * gouthamr is that a reference to something?
17:20:39 * gouthamr hi laggy, am not the Fand you're looking for..
17:20:59 <gouthamr> we had a couple of minor AIs on tracking Debian Trixie in the CI
17:21:28 <gouthamr> frickler had a devstack patch
17:21:30 <gouthamr> #link https://review.opendev.org/c/openstack/devstack/+/954653
17:21:32 <gouthamr> still WIP
17:21:37 <TheJulia> fungi: okay, I'm ignoring the actual back and forth on the discussion, should I be reading that. Where this has been a challenge is somehow folks trying to infer wholely owned subsidaries are legally the same company but it boils down to the legal responsibility of the command chain
17:22:16 <frickler> yes, waiting for trixie to be released before proceeding, so we can add in mirrors in opendev first
17:22:17 <TheJulia> i.e. if IBM legal, for example in-house counsel, were to approach me, I would be required to refer them to Red Hat legal (in-house counsel) because IBM legal is entirely outside of my structural chain of command
17:22:41 <gmaan> is this first one of do we have kolla or somewhere Debian Trixie job/test running
17:22:43 <gouthamr> ah ty frickler
17:23:00 <gmaan> frickler: ++
17:23:18 <gouthamr> in a similar vein, sean-k-mooney is trying to convert the Ceph job to use debian
17:23:41 <gouthamr> bookworm, because we'll wait on the image, mirrors, devstack support etc to exist to try this with trixie
17:23:47 <gouthamr> #link https://review.opendev.org/c/openstack/devstack-plugin-ceph/+/955714
17:24:07 <sean-k-mooney> that mainly to renable test cover by using one of our other supprot runtime
17:24:21 <sean-k-mooney> isntead fo just disabling the test becuse ubuntu has a packaging bug
17:24:24 <gmaan> ++, this is good example of distributing our testing among different distro
17:24:51 <sean-k-mooney> but yes bookworm not trixe bcasue of supprote runtime and the fact openstack does not work on trixy yet
17:25:06 <clarkb> and trixie isn't released
17:25:10 <sean-k-mooney> we coudl use trixie/13 next cycle after its released
17:25:19 <fungi> trixie release is schedule for next week
17:25:19 <gmaan> yeah, we cna move that to trixie later
17:25:32 <TheJulia> gmaan: the weirdness of on behalf of another company is... very weird, even more so for copyright since lineage is lost in such cases and thus really should be avoided at all costs.
17:25:42 <gmaan> sean-k-mooney: ++ make sense t use trixie in next cycle runtime
17:25:53 <sean-k-mooney> just keep in mind
17:26:03 <sean-k-mooney> trixie use python 3.13
17:26:08 <sean-k-mooney> and eventlet is not compatible with that
17:26:15 <gmaan> oh
17:26:16 <sean-k-mooney> so using it will be partly gated by that
17:26:24 <gmaan> py3.13, I did not realize that
17:26:25 <sean-k-mooney> i know zigo is activly trying to reslove that
17:26:40 <frickler> sean-k-mooney: iiuc all issues are resolved, tempest is passing
17:26:52 <gouthamr> TheJulia: ah, ack, ty - i don't know how easy it is to define that succinctly, but "legal responsibility of the command chain" may be invisible to the outside world.. lets discuss on the patch itself.. (sorry again for cutting this)
17:26:53 <sean-k-mooney> but its currently a blocker ot using it but it good to use as a smoketest/canary
17:27:00 <sean-k-mooney> frickler: really
17:27:04 <sean-k-mooney> that awsome news
17:27:15 <gouthamr> w00t, TIL
17:27:16 <frickler> the last issue was actually not py3.13, but a change in mariadb
17:27:25 <sean-k-mooney> oh the transaction thing
17:27:29 <frickler> yep
17:28:11 <sean-k-mooney> so then yes we shoudl stronctly consider adding trixe to the testing runtime for 2026.1 keeping bookworm for stable upgrade testing
17:28:34 <sean-k-mooney> and in 2026.2 we can drop bookwrom ot not infinetly grow the test matix
17:28:58 <gouthamr> good suggestion.. i'll work on the runtime update
17:29:04 <frickler> yes, currently the timetable looks like that will be feasible
17:29:23 <gouthamr> that's all the things we were working on that i see as AIs from our last meeting.. was anyone else working on anything to note?
17:29:32 <sean-k-mooney> for nova w are curently using debign to test some thing that redhat and canonical compile out fr what its worth. like spice supprot.
17:29:34 <gmaan> TheJulia: well, its about how those company/employee are contracted and allow them to use their affiliation which is again part of the contract. In summary, employee are on-site/deputed to their organization for particular duration. but yes we cannot cover all cases or assume things and mainly avoid legal checks
17:30:17 <TheJulia> gmaan: oh yeah, indeed. For example, there is a concept in close business relationships of dual badge employes
17:30:40 <sean-k-mooney> i mean in that case you could list both
17:30:41 <TheJulia> one some level, one company pays for that employee, but then and only then can that individual self identify who they are working on behalf of
17:31:11 <sean-k-mooney> but the affiation thing is mroe to disclose bias not a catch all for all influcance
17:31:21 <TheJulia> sean-k-mooney: quite possibly, granted in the cases I'm aware of those folks are not upstream contributors
17:32:20 <TheJulia> exactly, which is why its important to focus discussion on what is the common good
17:32:20 <gouthamr> all good inputs, lets talk on the gerrit proposal..
17:32:25 <gouthamr> #topic AI Working Group's White Paper - Call for Resources
17:32:29 <TheJulia> Yeah, I'm reading through the back and forth now
17:32:34 <fungi> #link https://lists.openstack.org/archives/list/openstack-discuss@lists.openstack.org/message/QGADCGXW2J5PJZKDH24VMJJJOM72GQTF/ OpenStack for AI Whitepaper coordination mailing list and meeting info
17:32:58 <fungi> anybody interested in ai workloads on openstack or tuning openstack deployments to support them should consider participating
17:33:15 <bauzas> I won't be able to join next meeting but I definitely plan to help for the whitepaper
17:33:53 <gouthamr> yes, i see a specific call out for folks that know the services deeply, i suspect we want to call out any features/architectures that are beneficial for AI workloads
17:34:02 <fungi> yeah, for those who haven't skimmed the announcement, just a reminder that the call is scheduled for 13:00 utc on thursday of this week (july 31)
17:34:20 <sean-k-mooney> there was a ptg seesion on this topic too last cycel
17:34:34 <sean-k-mooney> i assume there will be a simialr bird of a fether seesion at the sumit or next ptg
17:34:49 <gouthamr> i think they're trying to wrap up this paper by the Summit
17:35:23 <bauzas> correct
17:35:29 <sean-k-mooney> i assuem the effort will evovle into a working group or sig ot drive this usecase in openstack going forward
17:35:58 <sean-k-mooney> oh it is a working group already
17:36:02 <gouthamr> yes, it's a Foundation working group right now..
17:36:15 <gouthamr> (like the VMWare Migration Working Group)
17:36:16 <fungi> it's already organized as a foundation-level working group, but i could see some possibility for a mirrored structure within the openstack community too (like a sig maybe)
17:36:33 <bauzas> and there were some talks already
17:36:45 <bauzas> like showcases
17:37:39 <sean-k-mooney> well we know you can run ai workload on openstack (people have been doign it of year) btu there is defeily room for improvment so i will be interested to see what tehy whitepaper containes when its done
17:38:16 <gouthamr> if you're aware of these gaps,sean-k-mooney, an OpenStack SIG could be helpful - it'd be development focussed if we were to build specifically to address these AI use cases
17:38:19 <fungi> i think it's more about explaining how it's done by various organizations and covering the various use cases
17:38:34 <bauzas> zactly
17:38:54 <fungi> but sure, potential improvements to the platform to make that even better would probably also be a good outcome
17:38:54 <bauzas> but also collecting some needs
17:40:14 <gouthamr> lets chat about this some more at the 1300 UTC call this thursday
17:40:23 <gouthamr> anything else on $topic?
17:41:04 * gouthamr next up..
17:41:13 <gouthamr> #topic Proceeding with Monasca's retirement
17:41:18 <gouthamr> #link https://review.opendev.org/c/openstack/governance/+/953671/comments/05494668_4deb962f
17:41:33 <gouthamr> ^ thuvh told us that they'd prefer to get the project retired..
17:42:03 <gouthamr> the repos owned by the monasca team have no stable branches as we noted in last week's meeting
17:42:14 <gouthamr> just the "unmaintained/2023.1" branch
17:42:55 <bauzas> let it go then ?
17:43:11 <gouthamr> the unmaintained branch was already not the project team's responsibility - so i think we can consult the ML and unmaintained-core and proceed
17:44:04 <gmaan> I was not 100% sure if they are ok for retirement or they understood 'moving to legacy' correctly means that is retirement
17:44:17 <gmaan> but yes, their vote on the retirement change in governance can confirm it officially
17:44:46 <gmaan> just want to be more explicit in case there is any communication gap or gap in understanding of retirement
17:44:46 <fungi> also retirement is not irreversible, and doesn't really result in much difference with regard to the current state of activity in the project anyway
17:44:47 <gouthamr> i think you clarified that in your earlier comments on the change
17:45:30 <gouthamr> fungi: +1
17:45:33 <sean-k-mooney> the main impact is offically removing it form the integrated release coorect
17:45:35 <fungi> (sorry for the double-negative, should have said "retirement is reversible" i guess)
17:45:45 <sean-k-mooney> it can be unretired if folks really wanted too
17:45:49 <gouthamr> sean-k-mooney: it's not being released since 2023.1
17:45:55 <gmaan> ok because one time they said they want to maintain then after reading meeting logs ( which was more of discussion about how we can achieve healthy maintenance and avoid same situation again) they are ok for retirement
17:46:16 <sean-k-mooney> gouthamr: yep, its technially supprot in watcher as a backend but it has no docs/testing
17:46:17 <gmaan> I do not want to push pressure to them if they want to maintain.
17:46:38 <sean-k-mooney> we are offically decleering it deprecte/experimental this cycle adn considering if we would remove supprot in 2026.1
17:47:25 <sean-k-mooney> its retirement woudl factor into that too
17:48:09 <bauzas> this is already communicated afaik
17:48:33 <bauzas> now the question is whether we would retired it
17:49:09 <sean-k-mooney> i have no objection one way or another . but if it is retired it make droping supprot next cycle an easy desion for us
17:49:09 <gouthamr> sean-k-mooney: so to use it as a backend in this release, one would have to use watcher from 2025.2 and monasca-api from 2023.1 or older, i think?
17:49:24 <sean-k-mooney> yep
17:49:34 <sean-k-mooney> which may or may not be co installable
17:49:42 <sean-k-mooney> as i said we do not have ci for that and we are lackign docs
17:49:56 <sean-k-mooney> so we are not realy able to say its supproted
17:50:10 <gouthamr> ack
17:50:43 <gouthamr> okay, i'll take an AI to get this process rolling.. in the ML post, i'll mention the integration with watcher..
17:51:04 <gouthamr> #link https://review.opendev.org/c/openstack/watcher/+/941828
17:51:48 <gouthamr> tkajinam possesses clairvoyance of sorts
17:51:53 <gouthamr> ty for the call out here sean-k-mooney
17:51:58 <gouthamr> anything else for $topic?
17:52:07 <spotz[m]> Hehe
17:52:15 <fungi> i think tkajinam lives in the future and sends his changes to the past for us to review
17:52:27 <sean-k-mooney> we disucssed it at the ptg
17:52:41 <sean-k-mooney> we wanted to servay all the integration and backend this cycle
17:52:51 <sean-k-mooney> and understnd if we can supprot them and the level of testing
17:53:08 <sean-k-mooney> so we could comunitte the realtiy of where watcher really is today
17:53:10 <gouthamr> +1, i think this is a good effort! https://review.opendev.org/c/openstack/watcher/+/951699
17:53:41 <sean-k-mooney> so far the main output has been https://docs.openstack.org/watcher/latest/integrations/index.html#integration-status-matrix and https://docs.openstack.org/watcher/latest/strategies/index.html
17:54:16 <gouthamr> ty
17:54:20 <gouthamr> #topic A check on gate health
17:54:33 <gouthamr> ^ any gate concerns/updates this week?
17:55:37 <gmaan> one thing to mention
17:56:53 <gmaan> gibi fix (one of the possible root cause) on grenade job DB dump timeout is merged, if anyone still seeing that, please report
17:56:55 <gmaan> #link https://review.opendev.org/c/openstack/grenade/+/955865
17:57:27 <gmaan> we were seeing frequent timeout in grenade skip level job in last couple of week
17:57:35 <cardoe> ah I'm totally late.
17:57:56 <gouthamr> ack gmaan
17:58:15 <gouthamr> cardoe: hello
17:58:30 <sean-k-mooney> --skip-lock-tables makes sense in grenade
17:59:49 <gouthamr> we have under a minute
17:59:54 <gouthamr> so i'll skip to
17:59:59 <gouthamr> #topic Open Discussion
18:00:39 <gouthamr> just wanted to give a shoutout to the i18n interns, and their mentors ianychoi and seongsoo
18:00:44 <gouthamr> #link https://lists.openstack.org/archives/list/openstack-discuss@lists.openstack.org/thread/GGQAIF23Q3EEN5XRPZACM3E2FVLBQK26/
18:00:44 <gouthamr> 
18:00:56 <spotz[m]> Woot
18:01:23 <gouthamr> pretty nice summary from ian there, i'd recommend reading it.. i think we'll keep up with the progress there, and finish the zuul integration soon (TM)
18:01:38 <gouthamr> with that we're just over the hour..
18:01:52 <gouthamr> is there anything else you'd like to note in the minutes today?
18:03:02 <gouthamr> thank you all for attending, and staying the extra few minutes..
18:03:02 <gouthamr> #endmeeting