17:59:52 <knikolla> #startmeeting tc
17:59:52 <opendevmeet> Meeting started Tue Jun 20 17:59:52 2023 UTC and is due to finish in 60 minutes.  The chair is knikolla. Information about MeetBot at http://wiki.debian.org/MeetBot.
17:59:52 <opendevmeet> Useful Commands: #action #agreed #help #info #idea #link #topic #startvote.
17:59:52 <opendevmeet> The meeting name has been set to 'tc'
17:59:56 <knikolla> Hi all, welcome to the weekly meeting of the OpenStack Technical Committee
18:00:00 <knikolla> A reminder that this meeting is held under the OpenInfra Code of Conduct available at https://openinfra.dev/legal/code-of-conduct
18:00:04 <knikolla> Today's meeting agenda can be found at https://wiki.openstack.org/wiki/Meetings/TechnicalCommittee
18:00:07 <knikolla> #topic Roll Call
18:00:11 <dansmith> o/
18:00:14 <knikolla> o/
18:00:23 <gmann> o/
18:00:31 <knikolla> We have 2 noted absences for today. James and Jay.
18:00:33 <noonedeadpunk> o/
18:00:41 <knikolla> Hope those who attended the summit last week had a safe travel home.
18:02:23 <knikolla> tc-members: courtesy ping for meeting
18:02:31 <spotz_> o/
18:02:48 <spotz_> I was grabbing tea:)
18:03:07 <knikolla> #topic Follow up on past action items
18:03:12 <knikolla> There's 1 action item marked for me
18:03:16 <knikolla> knikolla To fix link redirect to release from docs
18:03:20 <knikolla> Due to the summit last week I have not been able to accomplish this item. I have therefore moved it to the TC tracker.
18:03:30 <knikolla> #link https://etherpad.opendev.org/p/tc-2023.2-tracker
18:03:32 <knikolla> As we are about 1/3 into the Bobcat cycle, I will start collecting updates on the tracker items from the individual assignees and start sending a monthly "Tracker update" email.
18:04:04 <knikolla> I'll also reach out individually to people assigned items to collect more context or note down action items or items that need discussion.
18:05:03 <knikolla> Nothing else from me on past action items
18:05:38 <knikolla> #topic Open Infra Summit retrospective
18:05:45 <knikolla> Last week was the OpenInfra Summit + PTG in Vancouver.
18:05:53 <knikolla> There were 750 attendees (IIRC), quite smaller compared to previous summits.
18:05:58 <dansmith> whoa
18:06:17 <knikolla> Some select updates, sessions and discussions of interest:
18:06:22 <knikolla> The OpenInfra foundation now has regional hubs in Europe and Asia.
18:06:22 <noonedeadpunk> however, I would say that most of sessions were way more advanced
18:06:36 <knikolla> The number of cores that OpenStack is managing has reached 40 million and is growing rapidly.
18:06:39 <noonedeadpunk> and qualities of discussions were leveled up, including formus
18:06:49 <gmann> this capture most of the highlights #link https://superuser.openinfra.dev/articles/openinfra-summit-vancouver-recap-50-things-you-need-to-know/
18:06:54 <knikolla> yep, the forum sessions were quite productive, and it was easier to network at this smaller scale.
18:07:14 <knikolla> #link https://superuser.openinfra.dev/articles/openinfra-summit-vancouver-recap-50-things-you-need-to-know/
18:07:19 <gmann> yeah but 30 min were less time for those, hoping we will have those of 1 hr at least in future
18:07:21 <knikolla> thanks for the link gmann
18:07:23 <fungi> not too much smaller than berlin i don't think, which was somewhere north of 800? but yeah, lots of people ended up with visa problems and had to cancel on short notice
18:07:46 <knikolla> The foundation said that over >100 people couldn't get a visa in time.
18:07:47 <spotz_> Overall I thought it was a great summit for the community, we had lots of great topics and new attendees
18:08:06 <noonedeadpunk> ++
18:08:10 <knikolla> All other forum etherpads can be found at
18:08:14 <knikolla> #link https://wiki.openstack.org/wiki/Forum/Vancouver2023
18:08:22 <knikolla> Forums of note:
18:08:28 <knikolla> Tuesday was the TC + Leaders interaction forum.
18:08:34 <knikolla> #link https://etherpad.opendev.org/p/tc-leaders-interaction-2023-vancouver
18:08:40 <knikolla> We discussed about gate job timeouts, SQLAlchemy 2.0 and Storyboard. Discussion is captured in Etherpad linked above.
18:08:49 <knikolla> #action JayF will write a proposal to capture the discussion related to SQLAlchemy 2.0 migration.
18:08:53 <knikolla> This includes a timeline for a requirements bump and possible retirement in the event of failure.
18:09:58 <knikolla> Anything else you feel is important to highlight from the tc+leaders interaction or comments on the above?
18:10:36 <spotz_> Just a note the Board session was scheduled to overlap so myself and a few others stepped out
18:11:54 <knikolla> On Wednesday we discussed about extended maintenance
18:12:00 <knikolla> #link https://etherpad.opendev.org/p/vancouver-2023-em
18:12:10 <knikolla> (I think this is the right etherpad though I see very few notes)
18:12:26 <knikolla> This was a short timeslot and most of the time was spent setting the context for the discussion.
18:12:33 <knikolla> My understanding of the outcome is
18:12:39 <knikolla> - There is a desire to keeping branches up and open.
18:12:44 <knikolla> - There was surprise from the attendees on the amount of effort from the maintainers to keep those branches working and patched.
18:12:49 <knikolla> - There was no pushback in renaming this to something that signals clearly that the branch is not maintained.
18:12:56 <knikolla> But we don't have any action items come out of this one.
18:13:55 <knikolla> Anyone else would like to add something?
18:14:50 <spotz_> I think the rename is a good idea, we just need to find the right name this time
18:15:20 <knikolla> The most fun part of software
18:15:20 <dansmith> a rename doesn't address my concern, although it sounds like a rename is *also* needed
18:15:28 <gmann> well, it is more than just rename.
18:15:31 <dansmith> I assume there's a ML thread coming based on previous comments right?
18:15:58 <gmann> upstream maintainer need to learn how to stop maintenance on those and just keep it open for operators to come forward and mainatibn
18:16:56 <gmann> operator does not expect us to maintain those and few of them remember the discussion from Sydney that it was external maintainers who was expected to maintain those
18:17:06 <fungi> what we didn't have time to get to is that we can't, logistically, grow an infinite number of open branches, so how to determine when to cut them loose and decide nobody is stepping forward to propose/review patches on them
18:17:53 <gmann> my proposal was to stop backport to EM and anyone need those EM and backport step up and propose backport
18:18:02 <knikolla> The forum really needed more time, but I think it was important in getting people on the same ground to understand that we don't want to spend resources on extended maintenance.
18:18:03 <gmann> and we help them in testing if it is broken
18:18:19 <fungi> and also that what we have now, with the default being we don't close branches unless the project asks us to, doesn't work so well when there's nobody to ask to close a defunct branch, so it needs to become opt-in with a dead-man switch defaulting to eol
18:18:23 <knikolla> And having that be uncontested by the audience.
18:18:51 <gmann> if we continue backport/fix test on every backport, same situation will happen that upstream team will get frustrated and propose to delete them
18:19:39 <dansmith> IMHO, as long as those branches are in the main trees, that will keep happening :)
18:19:41 <knikolla> Yeah
18:19:44 <gmann> until we do not draw that line for us we are not solving this issue, renaming is just one thing to do but that does not solve the issue
18:19:57 <gmann> dansmith: unfortunately, yes
18:21:25 <knikolla> I will schedule time during next TC's meeting and in the meanwhile I will try to collect the feedback into alternative proposals
18:21:45 <knikolla> And push those out through the ML
18:21:51 <knikolla> Seems fair?
18:22:24 <dansmith> so ML thread before next meeting?
18:22:43 <gmann> yeah, let's continue the discussion in ML before that
18:22:54 <knikolla> Yes.
18:23:56 <knikolla> We've heard input on things in general, now I want to group the various alternatives that I heard about into specific paths forwards and get input on those.
18:24:06 <knikolla> So not just discussing about EM in general.
18:24:57 <knikolla> Any objections/thoughts?
18:25:11 <knikolla> (about the process outlined)
18:25:29 <spotz_> nope
18:26:09 <dansmith> I mean, yes to ML thread.. I dunno about the "not just discussing about EM in general" part.. but I guess that depends on how well you enumerate every possible alternative proposal
18:26:24 <dansmith> I hope there's still room for coming up with new ideas
18:26:54 <knikolla> There's always room for new ideas
18:27:11 <dansmith> ...or revisiting old ones that seemed too difficult but maybe are a better fit for all the desires we've collected
18:28:24 <knikolla> Do you have a pointer to the old ones?
18:29:18 <dansmith> do you want to get into discussing alternatives here and now or are you just going over the discussions from last week?
18:29:26 <gmann> Initially I was not in favor of that but moving those into different namespace is not so bad idea. I know this need a lot of work but kinnda long term solution
18:29:42 <dansmith> gmann: that's the thing I'm referring to exactly :)
18:29:53 <dansmith> because I think it addresses several of the concerns
18:30:07 <gmann> let's discuss in ML I think so that we can have more audience and at some stage when we filter out/feedback then we can call out to decide one in TC meeting
18:30:07 <dansmith> it has its own challenges, for sure, but...
18:30:10 <dansmith> gmann: ++
18:30:12 <gmann> yeah
18:30:49 <knikolla> ah, i thought you meant some old idea from eons ago that was captured somewhere
18:30:56 <knikolla> in a land far away
18:31:03 <fungi> just be aware that having extra forks of our repositories in gerrit is also quite painful and i'd really rather avoid having to support that
18:31:26 <dansmith> doesn't have to be in gerrit, IMHO, but yes fungi I know infra is not a fan
18:32:05 <fungi> gerrit is not designed to make forks low-cost like some platforms, that's a tradeoff its designers made in favor of other optimizations
18:33:46 <knikolla> Moving on to the last forum session that I want to highlight? i18n.
18:33:57 <knikolla> #link https://etherpad.opendev.org/p/vancouver-2023-i18n-forum
18:34:08 <knikolla> The time for this session was also very limited and was mostly spent on setting the context and demonstrating the current process of translations with Zanata.
18:34:17 <knikolla> We reiterated the call for someone to work on the integration with Weblate after the upstream investment opportunity merged.
18:34:55 <knikolla> We haven't found that yet.
18:35:06 <knikolla> It might be valuable to investigate allowing translations for select governance documents, like Upstream Investment Opportunities.
18:36:40 <noonedeadpunk> I think there's another session forum that likely worth to be highlighted, regarding RBAC...
18:36:48 <noonedeadpunk> *forum session
18:37:07 <noonedeadpunk> #link https://etherpad.opendev.org/p/rbac-operator-feedback-vancouver2023
18:37:09 <knikolla> Please do provide some highlights from that, I wasn't able to attend it.
18:37:26 <gmann> I am preparing summary and will send on ML
18:37:35 <gmann> main ask from that is about global reader
18:38:13 <gmann> and public cloud use case of support admin kind of but that we have not solved with the current plan. something to do in future
18:38:18 <noonedeadpunk> Well, while we have reverted system scopes, there was nothing proposed as alternative to it, so usecases that were waited by public clouds for years just got kinda ignored after all...
18:38:53 <noonedeadpunk> And yes, global_reader is another thing that is needed and also has kinda fallen apart with that
18:39:10 <gmann> yeah, I know that is not solved but finishing project persona is good first step
18:39:31 <knikolla> We can fulfill some of the admin use cases that I heard with a "domain manager" sort of role in Keystone.
18:39:36 <gmann> we can add global reader as a special role in keystone so we do not need system scope for that
18:39:52 <knikolla> or rather, manager role with a domain scoped token.
18:39:54 <dansmith> we've discussed domain admin/manager in the past, and I agree it'd be ideal if we had that as well
18:40:09 <gmann> yeah, this is phase-3
18:40:09 <noonedeadpunk> I think main problem with "domain manager" is how to prohibit it assigning "admin" role to the project, that will be treated as global admin
18:40:40 <dansmith> I think there's some confusion over what scope a domain actually covers, as it seems not arbitrary, but there definitely seems like some gain to a mid-level admin like that
18:41:20 <gmann> yeah and we can stop domain manager to assign admin role and only domain admin can. at least this will solve public cloud issue.
18:41:23 <knikolla> noonedeadpunk: we can define that as a feature in Keystone. Perhaps a conf option or option on the domain.
18:41:32 <gmann> something special we need to do for domain manager
18:41:53 <knikolla> I can work with the Keystone team to write a spec for that.
18:41:55 <gmann> I was thinking a separate policy to assign admin role and default to domain admin
18:42:35 <noonedeadpunk> But yes, we can continue discussion in ML if you gmann was prepearing one
18:42:43 <knikolla> ++
18:42:43 <noonedeadpunk> (not to steal everyones time)
18:42:49 <gmann> yeah, will send today or tomorrow for sure
18:43:01 <knikolla> noonedeadpunk: time thief
18:43:20 <knikolla> Anything else on summit?
18:43:20 <noonedeadpunk> hehe :p
18:43:48 <dansmith> gmann: I think the missing thing for domain admin was to make it possible to have roles on the root domain, so global admin was just admin on the root domain,
18:43:57 <dansmith> but I think keystone can't do that currently or something
18:44:19 <dansmith> it's been a couple years since we discussed, but I remember that being a thing that would clean up the model a bit
18:44:29 <gmann> yeah
18:44:29 <knikolla> Root domain isn't exposed, as far as I remember, no.
18:44:33 <dansmith> right
18:45:43 <knikolla> #topic Gate health check
18:45:50 <knikolla> Did anything blow up while we were away?
18:46:01 <dansmith> I think something is blowing up right now with neutron?
18:46:15 <dansmith> https://bugs.launchpad.net/nova/+bug/2024160
18:46:33 <gmann> yeah, test_live_migration_with_trunk is  failing consistently
18:46:38 <fungi> network issues in rackspace caused problems with the mirror server in the dfw region, i think. there was a quick band-aid put in place over the weekend but we need to revisit it
18:47:02 <dansmith> fungi: seems like there are some ubuntu mirror issues as well, are those related>?
18:47:14 <fungi> are they ongoing?
18:47:22 <dansmith> some of my personal systems have been unable to fetch package updates from the main mirrors due to key issues
18:47:38 <fungi> oh, that would be unrelated then
18:47:47 <gmann> to unblock gate, current workaround for trunk test is to skip  #link https://review.opendev.org/c/openstack/tempest/+/886496
18:48:12 <knikolla> the CI for which timed out, fun.
18:48:53 <knikolla> alongside two failures
18:49:45 <gmann> its same test failing, need to check
18:51:57 <knikolla> anything else on the gate or action items to note down?
18:53:26 <knikolla> #topic Reviews and Open Discussion
18:53:33 <knikolla> #link https://review.opendev.org/q/project:openstack/governance+status:open
18:53:41 <knikolla> We're in pretty good shape with open reviews
18:54:38 <knikolla> Floor is open for anything that didn't find into the previous agenda items
18:56:01 <knikolla> Alright, thanks all!
18:56:06 <knikolla> use these 4 minutes that you get back wisely
18:56:08 <knikolla> #endmeeting