Thursday, 2022-02-24

*** pojadhav|out is now known as pojadhav|ruck02:52
*** pojadhav|ruck is now known as pojadhav|brb14:28
*** pojadhav|brb is now known as pojadhav|afk14:31
opendevreviewBelmiro Moreira proposed openstack/governance master: Release identification and release name  https://review.opendev.org/c/openstack/governance/+/82956314:32
opendevreviewGhanshyam proposed openstack/governance master: Define Zed cycle testing runtime  https://review.opendev.org/c/openstack/governance/+/83045414:48
gmann#startmeeting tc15:00
opendevmeetMeeting started Thu Feb 24 15:00:07 2022 UTC and is due to finish in 60 minutes.  The chair is gmann. Information about MeetBot at http://wiki.debian.org/MeetBot.15:00
opendevmeetUseful Commands: #action #agreed #help #info #idea #link #topic #startvote.15:00
opendevmeetThe meeting name has been set to 'tc'15:00
gmann#topic Roll call15:00
gmanno/15:00
dansmitho/15:00
belmoreirao/15:00
gmanntc-members: meeting time15:00
spotzo/15:00
jungleboyjo/15:00
slaweqo/15:01
diablo_rojoo/15:01
gmannlet's start15:02
gmann#link https://wiki.openstack.org/wiki/Meetings/TechnicalCommittee#Agenda_Suggestions15:02
gmanntoday agenda ^^15:02
gmann#topic Follow up on past action items15:02
gmannno action item from last meeting15:02
gmann#toic Gate health check15:02
yoctozeptoo/15:03
gmannany news on gate/15:03
dansmithnot from me, no major concerns that I've seen,15:04
fungijust a heads up, we're anticipating losing roughly 30% of our test capacity next month when inap turns off their openstack cloud (they're switching to all vmware apparently)15:04
dansmithoof15:04
jungleboyj:-(15:04
fungiwe're looking into some options, but should also degrade gracefully if we have to15:04
fungiit's supposedly going to be running until the end of march at least, so there's still some time to find alternatives15:05
diablo_rojoOwie15:05
gmannhumm15:05
spotz:(15:06
fungiworst case we can probably get some of our existing donors to temporarily up our quotas while we look for new donors to fill the gap15:06
fungitiming's not too bad since that'll be right after the yoga release15:07
gmannyeah that is good at least15:07
fungiand we tend to not overload our available capacity early in the development cycle15:07
gmannthere are few stable branch gate failure but me too have not noticed any major issue on master gate15:07
diablo_rojoOh thats goodish timing at least. 15:08
gmannbut losing 30% of capacity is big impact even at start of cycle15:08
spotzYeah that's a big chunk of resources15:08
fungiyeah, it's not great, but it's why we have a lot of donors and try not to put all of our eggs in one basket, as the addage goes15:08
gmannwhere we need to extend the upgrade testing for skip level thing15:08
* dmendiza[m] sneaks into the back of the room15:09
dansmithyeah :/15:09
fungii didn't mean to start a panic, just trying to keep everyone apprised and minimize surprises15:09
spotzI appreciate that fungi15:10
fungii'll make sure we keep everyone updated on any developments15:10
gmannyeah, let's see how it goes and if no other donner or it impact testing capacity as big then we can discuss. 15:10
jungleboyj++15:10
gmannthanks fungi for update. yeah please keep us posted.15:10
fungiit's also an opportunity to get some new donors involved ;)15:11
diablo_rojoThat would be cool :) 15:11
gmann+115:11
gmannanything else on gate health? 15:11
dansmithnot from me15:11
yoctozeptonope15:12
gmann#topic Z cycle Technical Elections15:12
gmannthere is no election required for PTL as well as for TC15:12
gmannwe are in process of closing the elections #link https://review.opendev.org/c/openstack/election/+/83054415:12
jungleboyj\o/15:12
gmannonce that is merged I will update the results in governance 15:12
gmannand time we end up with the 17 project with no nomination #link https://etherpad.opendev.org/p/zed-leaderless15:13
gmannbut most of them are just missed the election notification. which we have to discuss in PTG about how to improve15:13
jungleboyjYeah, that was kind of disappointing.15:14
gmannout of 17 we already have 11 projects have late nomination 15:14
gmannand 6 are still need some leaders15:14
diablo_rojoThat has been the growing trend, I've noticed. 15:14
jungleboyjThat isn't too bad.15:14
diablo_rojoMissing the deadlines. 15:15
diablo_rojoNice that so many have piped up already15:15
gmannthose 6 are Adjutant, Freezer, Murano, Solum, Trove, Watcher15:15
spotzYeah I'm not sure how to fix the communication issue gut glad we olny have 6 left and 1 we already were working on15:15
gmannI will check for Trove 15:16
gmannspotz: yeah15:16
gmannlet's start adding your opinion and some stats in etherpad and based on those we can discuss in next meeting or so15:16
gmannI will put stats next week once feature freeze is done15:17
gmannand once we close the election and also put these on ML15:17
gmannanything else on election thing?15:17
gmann#topic PTG Preparation15:18
gmann#link http://lists.openstack.org/pipermail/openstack-discuss/2022-February/027381.html15:18
gmann^^ sent email about PTG planning15:18
gmann#link https://etherpad.opendev.org/p/tc-zed-ptg15:18
gmann^^ etherpad to collect the topic, feel free to keep adding any topic you think we need to disucss15:19
gmannjungleboyj: can you plese add user survey which we need to cover in PTG?15:19
jungleboyjYes.  Will work on that.15:20
gmannthanks 15:20
gmannand to book slot before 11th Mar, I have created the doodle vote for checking the timing. #link https://doodle.com/poll/gz4dy67vmew5wmn915:21
gmannplease add your availability on this 15:21
spotzNot sure I hit submit yet, D&I WG already has a slot on Monday so may need to adjust things15:22
belmoreirashouldn't we wait for the new TC members? for the availability15:22
gmannbelmoreira: yeah, good point. it is open for all members including new or community members too15:22
gmannI will make sure we will not close it until we have new members onboard in TC15:23
jungleboyjAssuming that Cinder will be mornings of Tue-Fri, but will prioritize TC meetings.15:23
gmannand like we had TC+ Community leaders sessions in last PTG, we will continue that #link http://lists.openstack.org/pipermail/openstack-discuss/2022-February/027382.html15:24
gmannthere is doodle poll for that too #link https://doodle.com/poll/dcer6i3wk2b8eim315:24
diablo_rojospotz, if you remind me post meeting I can check for you15:24
gmannplease add your availability 15:24
spotzdiablo_rojo: On gmann's doodle? I know I did the ethercalc15:25
gmannspotz: I think no, i cannot see that.15:25
diablo_rojospotz, oh I thought you were talking about for the D&I working group signup survey15:25
diablo_rojoMy bad15:25
diablo_rojoMisread :) 15:26
gmannthat is all from me on PTG, just want to give headsup and will continue it in next meeting or until we have new members 15:26
gmannanything else from anyone on PTG or slot wise?15:26
gmann#topic Dropping tags framework - next steps (yoctozepto)15:27
gmannyoctozepto: please go ahead on updates15:28
yoctozeptopatches to release repo are proposed and pending to merge15:28
yoctozeptofungi has proposed the vmt patch15:28
yoctozeptoalso pending15:28
diablo_rojoShould I start outreach with the k8s folks?15:28
gmannyeah, #link https://review.opendev.org/c/openstack/releases/+/829014  #link https://review.opendev.org/c/openstack/releases/+/830084/215:28
gmannelodilles: ^^15:28
yoctozeptowe are waiting for website folks to confirm their removal15:28
gmann#link https://review.opendev.org/c/openstack/governance/+/83047815:29
fungiyeah, there's an "urgent" ticket open with tipit (the webdev contracting company the foundation uses) to remove the "project details" sections from pages like https://www.openstack.org/software/releases/xena/components/nova so that we won't end up with broken links there when the tag pages disappear15:29
fungii have a feeling it will be done by the end of the week (maybe even later today) but i'll let you know once it's clear15:29
yoctozeptothanks15:30
gmann thanks for handling that15:30
yoctozeptothe ossa dep has merged15:30
gmannyeah15:30
yoctozeptoyes, thank you fungi for helping!15:30
gmannso other that those we have two more remaining tags are 1. assert_follows-standard-deprecation 2. stable_follows-policy15:30
yoctozeptoso their content goes to project team guide15:31
yoctozeptoif it's missing there15:31
gmannyoctozepto: if I remember we need to move these (their documentation) to project-team-guide or some place right?15:31
gmannok15:31
yoctozeptoI have yet to do this15:31
yoctozeptoyeah15:31
gmannI can help on those next week.15:31
gmannsure, I will review them15:31
yoctozeptook, thanks, much appreciated15:31
gmannthen15:31
gmannthanks yoctozepto for working on those, anything else on this?15:32
gmann#topic "Artificially inflated requirements in os-brick​" (rosmaita)15:33
yoctozeptonot from my side15:33
gmannk15:33
gmann#link http://lists.openstack.org/pipermail/openstack-discuss/2022-February/027343.html15:33
gmann#link https://review.opendev.org/c/openstack/os-brick/+/82880215:33
gmannrosmaita: your turn15:33
rosmaitahello15:33
dansmithtbh, I had a hard time understanding the concern15:33
rosmaitai want to ask about this because i am about to artificially inflate the cinderclient requirements15:33
rosmaitawell, i think it's a packager/deployer consideration15:34
rosmaitamy question right now is does the TC feel I need to worry about this?15:34
yoctozeptoI think we have a general issue with handling the deps constraints15:34
yoctozeptoand these are just various blurps that we get15:34
dansmithyoctozepto: haven't we always?15:35
yoctozeptodansmith: yes, it's using present tense because it's still the case :D15:35
dansmithack :)15:35
fungiit raises the question why we bother to list versions in requirements files at all if we only really care that tests pass with our constraints list15:35
dansmithso part of the concern here is keeping deps old enough that they work on less than the most current OS versions while also moving them forward right?15:35
gmannrosmaita: and it is for consistency not like we have to bump due to incompatibility for cinder, python-cinderclient Yoga version 15:35
rosmaitawell, it's two things15:36
dansmithfungi: version ranges you mean right?15:36
fungidansmith: even that they work with "current" os versions, rather than whatever just got published to pypi yesterday15:36
yoctozeptowell, bumping regularly makes sense; though bumping to always-latest might not be15:36
rosmaitafirst is that i don't like listing minima that we haven't been testing with15:36
dansmithfungi: sure, sure15:36
rosmaitasecond is that i like to keep the requirements consistent across all the cinder project deliverables15:36
gmannso that is about testing lower constraints right15:37
yoctozeptogmann: +/-15:37
yoctozeptolower-constraints were not really tested well15:37
dansmithrosmaita: tbh, having brick's requirements not exactly equal to nova-compute is also as important as cinder/brick right?15:37
gmannyoctozepto: yeah. which is always the case15:37
yoctozeptomy issue is15:37
yoctozeptoif we are going to get 30% hit on gating capacity15:38
gmannmin vesions listed in req file is always not known that they work or not15:38
rosmaitadansmith: i think it mostly affects nova's lower-constraints job15:38
yoctozeptowe can't really say let's run devstack job alternatives with l-c15:38
yoctozeptoalso, l-c differ between projects15:38
fungiright, the friction is that there's no concrete way to manitain lists of lower bounds for dependencies in a way we can reliably test, but people want to be able to install our software without having to also update every last dependency even when those updates may contain only unrelated changes15:38
yoctozeptoso with our coinstallability requirement15:38
yoctozeptowe cannot do this15:38
gmanntrue15:38
dansmithrosmaita: I mean in reality.. people have to be able to install nova-compute and brick in the same environment, so they have to have a consistent set of reqs that work together15:38
yoctozepto(I don't like this requirement and think it's wrong nowadays but I understand people got used to it)15:38
gmannmain question is "what we want to convey with requirements.txt file" ?15:39
yoctozeptoand yeah, cases like dansmith mentioned15:39
rosmaitagmann: ++15:39
yoctozeptowhere openstack controls both the caller and the callee15:39
jungleboyjgmann: ++15:39
yoctozeptogmann: ++15:39
yoctozeptowhat we want and what we can, basically15:39
fungithe "cases" dansmith mentioned aren't a few isolated places we have to worry about coinstallability, they're representative of a large number of such interdeopendencies which need different projects installed together into the same environment15:40
gmannand having them inconsistent make then more wrost, like one case dansmith mentioned15:40
dansmithwell, with containers those pieces are smaller than all of openstack, which is the case for conventional packages15:40
yoctozeptoprecisely15:40
dansmithbut, things like brick tie certain pieces together which would otherwise be separate15:40
dansmithi.e. cinder and nova, linked through brick15:41
gmannI feel it at least (where we cannot test all the cases), making minima consistent with adjacent/used lib make sense 15:41
fungialso i can't see us telling "traditional distros" to take a hike and stop bothering trying to package openstack15:41
dansmithso, what if we tie our maximum to pip or whatever we need, and tie our minimum to ubuntu LTS or LTS-1 ?15:41
dansmithmeaning 18.04 right now, soon to be 20.0415:42
gmanndansmith: you mean for per repo or for all openstack ?15:42
dansmithfor lower-constraints, effectively15:42
dansmithI'm just thinking that maybe the skip-level job would give us testing at that older level, while also testing what a lot of people would actually be doing in terms of upgrades15:42
gmannbut that does not solve the current question from rosmaita. making few adjacent/related lib minima consistent ?15:43
fungithat seems on its face like it could be a reasonable compromise, but you'd actually need to test with those packages not what's on pypi, because the distros manually make those things coinstallable even when the python packages may say they can't be (they backport fixes and so on to old base versions)15:43
dansmithwell, part of his concern, I think, is that the minima aren't tested15:43
dansmithfungi: right15:43
fungiso we can't `pip install` the collective set of versions of our dependencies which are listed by those distros15:43
dansmithfungi: I guess we might need a delta of things that aren't shipped, but we'd need to know the precise formula of that delta and no more15:43
fungii do think it's reasonable to say that we simply lack the available resources to think about whether we need to update our dependencies, that distros should ignore the lower bounds they find in our python packages and test things themselves separately. i mean, it's more or less the position os-brick has taken, it's just not been stated clearly to the community15:45
dansmithyup15:46
rosmaitathat sounds good to me15:46
yoctozeptofungi: ++15:46
yoctozeptothat's reasonable15:46
gmannyeah, we should cleanup l-c completely to make it clear15:46
dansmithgmann: wouldn't that be nice :)15:47
fungiwe don't (and in my opinion realistically can't) manage and test minimum versions, as great as that would be. i tried to explain on the ml whythe concept is fundamentally flawed15:47
yoctozeptoand cleanup ranges in requirements.txt gmann15:47
gmannyoctozepto: yeah inclduing that15:47
yoctozeptoI'm all in15:47
yoctozeptothat's a clear message15:47
yoctozeptoplus a resolution15:47
dansmithso we have no l-c or u-c, just reqs.txt?15:47
yoctozeptoand we close this chapter15:47
yoctozeptodansmith: just reqs and u-c picking tested versions15:47
rosmaitai think we still need u-c15:47
fungii think we still need the upper constraints becaus ethat's how we pin our testing environments15:48
gmannI will add this to PTG to discuss it more and find some clear way instead of current mixed one.15:48
rosmaitafungi: ++15:48
dansmithI don't see why we need both15:48
fungiyes, it needs much more discussion with a broader cross-section of the community15:48
gmannyeah if l-c goes then we do not need both15:48
yoctozeptodansmith: we need upper boundary for testing coinstallability15:48
yoctozeptoreqs specify which of those are used by a project15:48
dansmithyoctozepto: we don't if we're not promising*any* ranges15:48
fungidansmith: i think we can drop version numbers from requirements.txt in projects, probably, but that too will need some experimenting15:49
dansmithyoctozepto: we could just have g-r, which is effectively u-c today as our requirements I think15:49
gmann#action gmann to add topic "lower bound versions direction as community" in PTG 15:49
yoctozeptodansmith: ugh, no idea how well g-r behaves nowadays15:49
yoctozeptoI think it's not used in many places15:49
yoctozeptoanyway, something to experiment with15:49
dansmithI think we're mincing words, but yeah15:50
fungii can exlpain the current state of global requirements management in detail, but not within the time remaining for this meeting15:50
spotzrosmaita: Is this something you need decided on before PTG or are you good with gmann's action item?15:50
rosmaitai am ok with ptg discussion, especially since15:50
rosmaitait appears everyone is OK with what i did with os-brick15:51
jungleboyj++15:51
rosmaitaand plan to do with cinderclient and cinder15:51
gmannrosmaita: anything blocking until we discuss in PTG?15:51
spotz++15:51
rosmaitano, i just wanted to get  a sense of whether this issue was considered a problem by the general community15:51
gmannrosmaita: yeah os-bricks way seems fine but I will say to do for cinder or client, let's wait for PTG outcome?15:51
gmannyeah it is surly an open confusion for long. 15:52
rosmaitai guess i could leave those alone15:52
rosmaitaexcept for oslo.vmware15:53
gmannok15:53
gmannanything else?15:53
rosmaitaok, i will be less aggressive with the requirements for cinderclient and cinder15:53
rosmaitano, that's all from me15:53
rosmaitathanks everyone15:54
gmannrosmaita: thanks for brining it, let's see if we can find some permanent solution this time15:54
gmann#topic Open Reviews15:54
gmann#link https://review.opendev.org/q/projects:openstack/governance+is:open15:54
gmann open reviews15:54
dansmithgmann: should I be rollcall vote'ing on my own resolution?15:54
gmanndansmith: yes, you can15:55
gmanndansmith: I saw one question there.15:55
dansmithokay so we're at 4 +1s there and several +1s from the community.. 15:55
dansmithyep, -1 from zigo, although I don't really understand.. he'd be +1 if we ticked and tocked more, but not just this amount :)15:56
gmannyeah, you replied, i did not see15:56
yoctozeptowell, zigo raised the just-discussed issue as well so15:56
gmannnumber of votes are good, we just need to wait for 3 more days as per formal-vote process15:56
dansmithokay, that was my next question, thanks :)15:56
belmoreirawe also discuss it in the previous video meeting for this topic15:57
gmannyeah15:57
belmoreirathis is an important change. It would be great to have all the TC represented in the change15:57
* jungleboyj has a tab open15:58
* yoctozepto has a tab open too15:58
* yoctozepto expects a RV+1 tbh15:58
gmannit is mergeable on 28th, I will do15:58
* spotz has lots of tabs15:59
gmannyeah, the current TC votes as per on 28th15:59
dansmithwe should also get belmoreira's as soon as it's allowed, before he disappears, IMHO15:59
dansmithI mean.. "disappears" :)15:59
yoctozeptoyeah, I was about to ask15:59
yoctozeptoif you plan a kidnapping15:59
dansmithyoctozepto: too soon15:59
yoctozeptoyeah15:59
dansmith:P15:59
belmoreira:)15:59
gmann:)15:59
gmannother thing i pushed zed testing runtime #link https://review.opendev.org/c/openstack/governance/+/83045415:59
gmannkeeping ubuntu20.04 as 22.04 is planned to release on 21st April which is after Zed cycle start16:00
gmannany concern on that?16:00
yoctozeptono, we can update later16:00
dansmithI need to re-+1 both of those16:00
yoctozeptowell, "you" can :D16:00
gmannyoctozepto: humm, I am thinking not to do.16:00
gmannand consider in AA ?16:00
spotzAre we tested on it?16:01
yoctozeptogmann: we/you can query the community16:01
dansmithyeah, IMHO, we should not shift the Z reqs late and just call this good16:01
yoctozeptoand, well16:01
gmannspotz: on 22.04 ?16:01
yoctozeptoif QA can handle this16:01
gmanndansmith: yeah16:01
yoctozeptoI would stay on 20.04 too16:01
gmannyoctozepto: I do not think so, I am doing mostly the migration for last few times and it involve lot of testing16:02
yoctozeptogmann: yeah, I know the drill16:02
spotzgmann: teah16:02
yoctozeptoand can't help nowadays16:02
gmannspotz: that is not yet, as not released officially 16:02
yoctozeptoso let's not ruin Zed because of this16:02
yoctozeptowe're past time16:03
gmannyeah, lot of other things also we need to finish like RBAC etc16:03
yoctozeptoOH NO16:03
gmannanyways we are out of time, please review and add you vote there16:03
yoctozeptothanks gmann16:03
yoctozeptotake care16:03
jungleboyjgmann:  Thanks!16:03
gmannthat is all for today, next meeting will be video call. I will add link there16:04
gmannthanks all for joining16:04
gmann#endmeeting16:04
opendevmeetMeeting ended Thu Feb 24 16:04:10 2022 UTC.  Information about MeetBot at http://wiki.debian.org/MeetBot . (v 0.1.4)16:04
opendevmeetMinutes:        https://meetings.opendev.org/meetings/tc/2022/tc.2022-02-24-15.00.html16:04
opendevmeetMinutes (text): https://meetings.opendev.org/meetings/tc/2022/tc.2022-02-24-15.00.txt16:04
opendevmeetLog:            https://meetings.opendev.org/meetings/tc/2022/tc.2022-02-24-15.00.log.html16:04
spotzThanks gmann and everyone!16:04
diablo_rojoThanks gmann!16:04
*** pojadhav|afk is now known as pojadhav|out16:25
*** ykarel is now known as ykarel|away16:31
opendevreviewMerged openstack/election master: Close out Zed elections  https://review.opendev.org/c/openstack/election/+/83054422:06
opendevreviewGhanshyam proposed openstack/governance master: Close Zed PTL Elections  https://review.opendev.org/c/openstack/governance/+/83091022:38
opendevreviewGhanshyam proposed openstack/governance master: Close TC Zed election  https://review.opendev.org/c/openstack/governance/+/83091523:03

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