Tuesday, 2023-05-16

opendevreviewMerged openstack/election master: Switch to 2023.2 testing runtime py version  https://review.opendev.org/c/openstack/election/+/88113802:52
noonedeadpunkHey, not sure I will be in time for the meeting, dealing with visa stuff now15:24
JayFThanks for the heads up16:04
gmannJayF: do you want to update the agenda in wiki, date and action items  I think17:46
JayFah, I thought those action items looked familiar17:47
gmannthose action items were from old meeting not from previous one17:47
gmannwe covered them in last meeting17:47
JayFack makes sense17:47
gmannthere seems no action item from last meeting https://meetings.opendev.org/meetings/tc/2023/tc.2023-05-09-17.59.html17:47
JayFI'm going to pull the other items we discussed last meeting17:47
JayFbroken docs and python version support+libraries17:47
JayFyeah?17:47
JayFor do we wanna go back into that today17:48
JayFwdyt gmann 17:48
gmannI think we can keep as they are not finished but can be skipped if no updates or so17:48
noonedeadpunkfwiw, I'm quite confused about https://lists.openstack.org/pipermail/openstack-discuss/2023-May/033683.html as I'm pretty sure it's not where we ended up with17:49
noonedeadpunkI wonder if we should raised that topic again or just discuss on the ML directly as agreement was reached in TC I believe. We even did voting iirc17:50
gmannnoonedeadpunk: but we kept zed just open if anyone comes to maintain it. I am not worried if testing is stopped and it is all broken17:51
JayFbasically we're not closing the door if someone shows up with a crew of maintainers and wants to take over zed17:51
gmannI mean that is best we can do when no mainainter for zed 17:52
fungiyes, it's available to be maintained by anyone who shows up. we can't tell volunteers they have to fix their ci17:52
JayFbut unless that happens, zed tripleo will waste away17:52
gmannyeah17:52
dansmithI've got some other stuff going on that will make me distracted during the meeting, FWIW17:55
JayFMaybe we'll just have a nice quick one then :)17:55
JayFtc-members: 5 minutes until tc meeting17:55
jamespageI have a similar challenge and need to move location part way through the hour17:56
JayF#startmeeting tc18:00
opendevmeetMeeting started Tue May 16 18:00:23 2023 UTC and is due to finish in 60 minutes.  The chair is JayF. Information about MeetBot at http://wiki.debian.org/MeetBot.18:00
opendevmeetUseful Commands: #action #agreed #help #info #idea #link #topic #startvote.18:00
opendevmeetThe meeting name has been set to 'tc'18:00
JayFWelcome to the weekly meeting of the technical committee.18:00
JayFA reminder that this meeting is held under the OpenInfra Code of Conduct available at https://openinfra.dev/legal/code-of-conduct18:00
JayF#topic Roll Call18:00
dansmitho/18:00
JayFo/18:00
gmanno/18:00
slaweqo/18:01
JayFknikolla is off this week; so I'm chairing the meeting18:01
rosmaitao/18:01
jamespageo/18:02
JayFAlright, that looks like quorum. Getting starting.18:02
JayFNo action items from last meeting; so I'm skipping this agenda item.18:02
JayF#topic Gate Health Check18:02
JayFhow is the gate looking?18:02
spotz_o/18:03
JayFI'll note for Ironic; our boot-from-volume job was broken by the Cinder bugfix. We're pretty sure Ironic<>Cinder is broken in any branch that had the fix backported into. We're working on a fix of our own to backport, but progress is slow.18:03
dansmithcould be better (always) but seems pretty good lately18:03
dansmithJayF: the cinder cve change you mean?18:03
JayFYEs.18:03
slaweqI think that (at least in neutron) we finally get it better than last few weeks18:04
gmannI have not observed much failure on master18:04
dansmithack, I did not know you guys consume cinder directly18:04
dansmithunfortunately I expect we'll see knock-on effects from that change for a while to come yet18:04
JayFYes, we do. We had a conversation with fungi about how, once this is all over, we'd like to have some kind of follow up meeting/conversation/etc18:04
gmannwallaby ceph job is broken and requried os-brick fix is backported but as wallaby is EM we cannot release this lib18:04
noonedeadpunko/18:05
JayFgmann: so does that mean wallaby ceph support has to go away? No way around it?18:05
dansmithno there are ways around it,18:05
spotz_Could someone just apply the patch themselves?18:05
dansmithbut it's EM and usually not fixing jobs when they break is how we handle those things18:05
gmannI will try if that work with fix released version or master os-brick in job18:05
gmannspotz_: its job take the version from upper constraints18:06
fungialternatively, stable/wallaby of os-brick could be installed instead of installing the release from pypi18:06
gmannbut I will try if any way we can mention the fix release version in job and if that is being picked 18:06
dansmithfungi: you mean the git tree18:06
fungijust make it a required-project in the job and it should end up getting installed from source of the corresponding branch18:07
gmannyeah18:07
gmannrequired-project and override branch with stable/wallaby18:07
JayFThat's how  we test changes in EM branches of libraries like sushy in Ironic18:07
JayFAs unfortunate as it is that we have specific items we're complaining about with gate this week; it's better than the "everything is flakey due to X" reports that are sometimes common. These all sound fixable :)18:07
JayFIs there anything further about the gate or should we move on?18:08
JayFMoving on.18:08
JayF#topic Broken docs due to inconsistent naming18:08
JayFIt's unclear if there's anything left to discuss on this topic. Does anyone have something to share?18:09
fungidod the proposed fixes correct it?18:10
fungis/dod/did/18:10
gmannit is not merged yet, there are few review comments on that18:10
fungi#link https://docs.openstack.org/2023.1.antelope/user/18:10
fungithat still looks pretty empty18:10
JayF#link https://review.opendev.org/c/openstack/openstack-manuals/+/88129018:11
JayFis the proposed fix, it has negative feedback to be addressed18:11
gmannyeah18:11
JayFGiven it's Kristi's patch; I'd assume his time off has put this on pause.18:11
fungigot it. so still under review18:11
JayFI'm going to move on then18:11
JayF#topic  Schedule of removing support for Python versions by libraries - how it should align with coordinated releases (tooz case)18:12
JayF#link https://review.opendev.org/c/openstack/governance/+/88216518:12
gmannwe have some comment on proposed PTI, noonedeadpunk not sure if you got time to check those?18:12
JayF#link https://review.opendev.org/c/openstack/governance/+/88215418:12
JayFare both still under review, I encourage TC members to review them18:13
gmannI think we can discuss it here if noonedeadpunk is ok ?18:13
gmannI feel we should make py3.8 r any future runtime same for everyone not just for lib18:13
gmannotherwise it will be difficult to coordinate and keep it working in the way we want18:14
JayFI think there's value in having some of those discussions async in Gerrit, but if we think we can make a quick breakthrough here that's likely good18:14
noonedeadpunkwell, we can do that, but there was a valid point that we should have a way to deprecate old python versions overall18:14
noonedeadpunkand coordinate this somehow. Having that as community goal might not be enough, as some will still need to drop support first18:15
gmanndeprecated ?18:15
noonedeadpunk*remove18:15
gmannk18:15
gmanngoal can give us benefit of planning right like one or two people planning what should drop first and what at end18:16
JayFIt seems to me we have two separate, related problems: 1) unwinding the breakages that hurt bobcat development (this is done?) and 2) figuring out how to remove python versions moving forward18:16
opendevreviewJeremy Stanley proposed openstack/openstack-manuals master: Attempt at fixing broken docs  https://review.opendev.org/c/openstack/openstack-manuals/+/88129018:16
JayF#1 is urgent, #2 needs to be solved by end-of-cycle... yeah?18:16
gmann1 is done as we have py38 voting job now18:17
noonedeadpunkit's done, but not documented18:17
JayFOk, so the problems remaining need addressing this cycle, but we don't have to treat it urgently. That's nice. 18:17
gmannI think 2nd also urgent as not all project are up to dated on our discussion so having our pti updated is important 18:17
noonedeadpunkyeah18:17
JayFWell, we can update the state of the art for Bobcat18:18
JayFwithout solving future project management problems (which is essentially what the python retirement is)18:18
JayFyeah?18:18
noonedeadpunkI will check comments on the patch shortly and will have another round of thinking what we can do there18:18
gmannwe do not have py38 in bobcat testing runtime so any project can argue to drop it that is why updating PTI is also important18:18
gmannnoonedeadpunk: +1 thanks 18:18
noonedeadpunkas again, I'm not sure we should oblige everyone to have 3.8 support when we don't support any platform that has it natively18:19
JayFI look forward to seeing the updates in the patch.18:19
JayFIt seems like that's where things are going, so I'm going to move the meeting along if so?18:19
gmannI am ok with that if we are able to clearly list what all projects to keep and who all can drop. lib is not defined term here18:19
JayFMoving on.18:20
JayF#topic Bare recheck state18:20
JayFHow are rechecks looking like?18:20
noonedeadpunkgmann: ++18:20
JayF#link https://etherpad.opendev.org/p/recheck-weekly-summary18:20
slaweqall good with rechecks18:21
slaweqnumbers are pretty ok18:21
JayFThanks for aggregating that data!18:21
JayFAnything else before we move on?18:21
slaweqnothing from me18:21
JayF#topic Open Reviews 18:22
JayF#link https://review.opendev.org/q/projects:openstack/governance+is:open18:22
JayFWe have a lot of governance patches up for review right now; please find time to review and vote and/or comment.18:22
slaweqI will try to go through them tomorrow morning18:23
JayFThat's the last item on the agenda. Is there any comments about open reviews, or anything else that needs to be addressed in the TC meeting before we close it for today?18:23
gmannI think many of them are depends-on on project config changes18:23
JayFI'm going to close up the meeting.18:25
JayFthank you everyone for your participation18:25
JayF#endmeeting18:25
opendevmeetMeeting ended Tue May 16 18:25:09 2023 UTC.  Information about MeetBot at http://wiki.debian.org/MeetBot . (v 0.1.4)18:25
opendevmeetMinutes:        https://meetings.opendev.org/meetings/tc/2023/tc.2023-05-16-18.00.html18:25
opendevmeetMinutes (text): https://meetings.opendev.org/meetings/tc/2023/tc.2023-05-16-18.00.txt18:25
opendevmeetLog:            https://meetings.opendev.org/meetings/tc/2023/tc.2023-05-16-18.00.log.html18:25
slaweqo/18:25
slaweqgood night :)18:25
gmannthanks JayF,  everyone 18:25
JayFo/ np18:25
funginoonedeadpunk: after rereading the update for tripleo, i think i see the concern you're raising. see if what i called out specifically in my reply summarizes it18:26
spotz_thanks JayF18:26
fungimost of the message was about downstream testing in rdo/delorean which doesn't really impact upstream, but dropping the zed zuul jobs from the openstack/tripleo-ci project would18:26
fungii had skimmed past that bit near the end of the message the first time i read through it18:27
noonedeadpunkfungi: it was also about phrase "there should be no more patches submitted for stable/zed TripleO repos, and any backports will go..."18:27
fungiif those developers aren't maintaining the newer branches (by their own admission) then they shouldn't be removing jobs from those branches18:28
noonedeadpunkBut yes, what you wrote is basically what concerned me the most18:29
fungithere's no strict requirement that community members also push patches to newer branches though when they're pushing them for extended maintenance branches18:29
noonedeadpunksure not, but prohibiting anyone to be able to do so is also wrong18:29
fungiif someone's interested in forward-porting patches from stable/wallaby to later branches then they can do that themselves (and also work on fixing ci jobs for those later branches)18:30
fungii didn't read it as a prohibition, just a poorly-worded version of "the people who were doing that before won't be doing it any longer"18:30
noonedeadpunkYes, but statement "there should be no more patches submitted for stable/zed" is wrong then, isn't it?18:30
JayFI read an implied (by us) at the end of that message18:30
JayFbut you're right it should have been made explicit18:31
fungiit depends on how strictly you interpret their use of the english language in that sentence18:31
fungii agree it was vague, but i interpreted it as not being a prohibition simply because they're not in a position to prohibit anything18:31
noonedeadpunkwell, along with fully dropping CI...18:31
noonedeadpunkor patch proposing that at least - that sounded quite strong18:31
fungii do agree that altering maintained stable branches to remove jobs is out of bounds18:31
noonedeadpunkI'm not sure they're understanding that they're not in position to prohibit that18:32
noonedeadpunkAs I feel their perception to not care about 3 out of 4 opens18:33
noonedeadpunkI could be wrong though18:33
JayFYes they are-ish. They are DPL. If the people who are DPL wanna remove those jobs, they can.18:33
JayFThis is why it's such a dubious thing. We (TC) explicitly enabled a group that disclaimed interest in tripleo stable/zed to have control over it.18:33
JayFRightly or wrongly, that's how we delegated.18:34
JayFWe can un-delegate, if we so desire, but right now I think we're worrying about the rights of some mythical new-tripleo-contributor that doesn't exist.18:34
fungii think what we're arguing for is that if these people said they're no longer maintaining tripleo, the tc can step in and remove their control over the project in gerrit (and can grant them exclusive control over stable/wallaby approvals if that's still desired)18:34
fungii'm dubious as to why they would care that there are still jobs configured for stable/zed if they're claiming they no longer have any interest in doing anything with stable/zed anyway18:35
JayFThat's maybe a good question to ask directly on the lsit.18:35
JayF*list18:35
fungimaybe the crux of this is that the project-template being altered in 882759 is applied to master-branch-only deliverables they're still maintaining (because they're used by stable/wallaby branches of other deliverables), and they don't want to have to fix stable/zed of those branched deliverables to unblock changes for the master-branch-only deliverables18:37
JayFI suspect that, or some similar technical-fiddliness is the motivation, not trying to salt the field if someone comes separately18:38
JayFmight be worthwhile to explicitly say "ignoring stable/zed, and that your changes break it, is OK"18:38
JayF(afaict, it is, yeah?)18:39
noonedeadpunkyes, that would be way better phrasing and intention18:43
opendevreviewJeremy Stanley proposed openstack/openstack-manuals master: Attempt at fixing broken docs  https://review.opendev.org/c/openstack/openstack-manuals/+/88129019:03
opendevreviewJeremy Stanley proposed openstack/openstack-manuals master: Attempt at fixing broken docs  https://review.opendev.org/c/openstack/openstack-manuals/+/88129019:41

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