15:00:07 <gmann> #startmeeting tc
15:00:07 <opendevmeet> Meeting 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:07 <opendevmeet> Useful Commands: #action #agreed #help #info #idea #link #topic #startvote.
15:00:07 <opendevmeet> The meeting name has been set to 'tc'
15:00:11 <gmann> #topic Roll call
15:00:14 <gmann> o/
15:00:18 <dansmith> o/
15:00:20 <belmoreira> o/
15:00:31 <gmann> tc-members: meeting time
15:00:37 <spotz> o/
15:00:49 <jungleboyj> o/
15:01:41 <slaweq> o/
15:01:43 <diablo_rojo> o/
15:02:00 <gmann> let's start
15:02:02 <gmann> #link https://wiki.openstack.org/wiki/Meetings/TechnicalCommittee#Agenda_Suggestions
15:02:06 <gmann> today agenda ^^
15:02:15 <gmann> #topic Follow up on past action items
15:02:46 <gmann> no action item from last meeting
15:02:57 <gmann> #toic Gate health check
15:03:01 <yoctozepto> o/
15:03:04 <gmann> any news on gate/
15:04:03 <dansmith> not from me, no major concerns that I've seen,
15:04:10 <fungi> just 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:21 <dansmith> oof
15:04:25 <jungleboyj> :-(
15:04:35 <fungi> we're looking into some options, but should also degrade gracefully if we have to
15:05:13 <fungi> it's supposedly going to be running until the end of march at least, so there's still some time to find alternatives
15:05:34 <diablo_rojo> Owie
15:05:49 <gmann> humm
15:06:05 <spotz> :(
15:06:19 <fungi> worst case we can probably get some of our existing donors to temporarily up our quotas while we look for new donors to fill the gap
15:07:12 <fungi> timing's not too bad since that'll be right after the yoga release
15:07:23 <gmann> yeah that is good at least
15:07:34 <fungi> and we tend to not overload our available capacity early in the development cycle
15:07:43 <gmann> there are few stable branch gate failure but me too have not noticed any major issue on master gate
15:08:05 <diablo_rojo> Oh thats goodish timing at least.
15:08:24 <gmann> but losing 30% of capacity is big impact even at start of cycle
15:08:50 <spotz> Yeah that's a big chunk of resources
15:08:51 <fungi> yeah, 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 goes
15:08:53 <gmann> where we need to extend the upgrade testing for skip level thing
15:09:00 * dmendiza[m] sneaks into the back of the room
15:09:16 <dansmith> yeah :/
15:09:42 <fungi> i didn't mean to start a panic, just trying to keep everyone apprised and minimize surprises
15:10:07 <spotz> I appreciate that fungi
15:10:25 <fungi> i'll make sure we keep everyone updated on any developments
15:10:38 <gmann> yeah, let's see how it goes and if no other donner or it impact testing capacity as big then we can discuss.
15:10:52 <jungleboyj> ++
15:10:54 <gmann> thanks fungi for update. yeah please keep us posted.
15:11:03 <fungi> it's also an opportunity to get some new donors involved ;)
15:11:16 <diablo_rojo> That would be cool :)
15:11:22 <gmann> +1
15:11:39 <gmann> anything else on gate health?
15:11:52 <dansmith> not from me
15:12:15 <yoctozepto> nope
15:12:21 <gmann> #topic Z cycle Technical Elections
15:12:35 <gmann> there is no election required for PTL as well as for TC
15:12:44 <gmann> we are in process of closing the elections #link https://review.opendev.org/c/openstack/election/+/830544
15:12:51 <jungleboyj> \o/
15:12:55 <gmann> once that is merged I will update the results in governance
15:13:31 <gmann> and time we end up with the 17 project with no nomination #link https://etherpad.opendev.org/p/zed-leaderless
15:13:49 <gmann> but most of them are just missed the election notification. which we have to discuss in PTG about how to improve
15:14:16 <jungleboyj> Yeah, that was kind of disappointing.
15:14:30 <gmann> out of 17 we already have 11 projects have late nomination
15:14:39 <gmann> and 6 are still need some leaders
15:14:53 <diablo_rojo> That has been the growing trend, I've noticed.
15:14:55 <jungleboyj> That isn't too bad.
15:15:04 <diablo_rojo> Missing the deadlines.
15:15:14 <diablo_rojo> Nice that so many have piped up already
15:15:24 <gmann> those 6 are Adjutant, Freezer, Murano, Solum, Trove, Watcher
15:15:35 <spotz> Yeah I'm not sure how to fix the communication issue gut glad we olny have 6 left and 1 we already were working on
15:16:00 <gmann> I will check for Trove
15:16:11 <gmann> spotz: yeah
15:16:48 <gmann> let's start adding your opinion and some stats in etherpad and based on those we can discuss in next meeting or so
15:17:04 <gmann> I will put stats next week once feature freeze is done
15:17:29 <gmann> and once we close the election and also put these on ML
15:17:43 <gmann> anything else on election thing?
15:18:26 <gmann> #topic PTG Preparation
15:18:31 <gmann> #link http://lists.openstack.org/pipermail/openstack-discuss/2022-February/027381.html
15:18:38 <gmann> ^^ sent email about PTG planning
15:18:46 <gmann> #link https://etherpad.opendev.org/p/tc-zed-ptg
15:19:08 <gmann> ^^ etherpad to collect the topic, feel free to keep adding any topic you think we need to disucss
15:19:27 <gmann> jungleboyj: can you plese add user survey which we need to cover in PTG?
15:20:16 <jungleboyj> Yes.  Will work on that.
15:20:57 <gmann> thanks
15:21:00 <gmann> and to book slot before 11th Mar, I have created the doodle vote for checking the timing. #link https://doodle.com/poll/gz4dy67vmew5wmn9
15:21:18 <gmann> please add your availability on this
15:22:00 <spotz> Not sure I hit submit yet, D&I WG already has a slot on Monday so may need to adjust things
15:22:12 <belmoreira> shouldn't we wait for the new TC members? for the availability
15:22:39 <gmann> belmoreira: yeah, good point. it is open for all members including new or community members too
15:23:01 <gmann> I will make sure we will not close it until we have new members onboard in TC
15:23:30 <jungleboyj> Assuming that Cinder will be mornings of Tue-Fri, but will prioritize TC meetings.
15:24:20 <gmann> and 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.html
15:24:31 <gmann> there is doodle poll for that too #link https://doodle.com/poll/dcer6i3wk2b8eim3
15:24:33 <diablo_rojo> spotz, if you remind me post meeting I can check for you
15:24:41 <gmann> please add your availability
15:25:11 <spotz> diablo_rojo: On gmann's doodle? I know I did the ethercalc
15:25:39 <gmann> spotz: I think no, i cannot see that.
15:25:42 <diablo_rojo> spotz, oh I thought you were talking about for the D&I working group signup survey
15:25:51 <diablo_rojo> My bad
15:26:03 <diablo_rojo> Misread :)
15:26:28 <gmann> that 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:49 <gmann> anything else from anyone on PTG or slot wise?
15:27:51 <gmann> #topic Dropping tags framework - next steps (yoctozepto)
15:28:07 <gmann> yoctozepto: please go ahead on updates
15:28:16 <yoctozepto> patches to release repo are proposed and pending to merge
15:28:29 <yoctozepto> fungi has proposed the vmt patch
15:28:31 <yoctozepto> also pending
15:28:34 <diablo_rojo> Should I start outreach with the k8s folks?
15:28:38 <gmann> yeah, #link https://review.opendev.org/c/openstack/releases/+/829014  #link https://review.opendev.org/c/openstack/releases/+/830084/2
15:28:44 <gmann> elodilles: ^^
15:28:54 <yoctozepto> we are waiting for website folks to confirm their removal
15:29:04 <gmann> #link https://review.opendev.org/c/openstack/governance/+/830478
15:29:22 <fungi> yeah, 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 disappear
15:29:57 <fungi> i 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 clear
15:30:05 <yoctozepto> thanks
15:30:16 <gmann> thanks for handling that
15:30:21 <yoctozepto> the ossa dep has merged
15:30:26 <gmann> yeah
15:30:31 <yoctozepto> yes, thank you fungi for helping!
15:30:48 <gmann> so other that those we have two more remaining tags are 1. assert_follows-standard-deprecation 2. stable_follows-policy
15:31:09 <yoctozepto> so their content goes to project team guide
15:31:12 <yoctozepto> if it's missing there
15:31:13 <gmann> yoctozepto: if I remember we need to move these (their documentation) to project-team-guide or some place right?
15:31:18 <gmann> ok
15:31:20 <yoctozepto> I have yet to do this
15:31:21 <yoctozepto> yeah
15:31:23 <gmann> I can help on those next week.
15:31:31 <gmann> sure, I will review them
15:31:31 <yoctozepto> ok, thanks, much appreciated
15:31:32 <gmann> then
15:32:16 <gmann> thanks yoctozepto for working on those, anything else on this?
15:33:04 <gmann> #topic "Artificially inflated requirements in os-brick​" (rosmaita)
15:33:05 <yoctozepto> not from my side
15:33:12 <gmann> k
15:33:15 <gmann> #link http://lists.openstack.org/pipermail/openstack-discuss/2022-February/027343.html
15:33:24 <gmann> #link https://review.opendev.org/c/openstack/os-brick/+/828802
15:33:39 <gmann> rosmaita: your turn
15:33:39 <rosmaita> hello
15:33:50 <dansmith> tbh, I had a hard time understanding the concern
15:33:59 <rosmaita> i want to ask about this because i am about to artificially inflate the cinderclient requirements
15:34:12 <rosmaita> well, i think it's a packager/deployer consideration
15:34:47 <rosmaita> my question right now is does the TC feel I need to worry about this?
15:34:48 <yoctozepto> I think we have a general issue with handling the deps constraints
15:34:56 <yoctozepto> and these are just various blurps that we get
15:35:04 <dansmith> yoctozepto: haven't we always?
15:35:20 <yoctozepto> dansmith: yes, it's using present tense because it's still the case :D
15:35:28 <dansmith> ack :)
15:35:54 <fungi> it 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 list
15:35:56 <dansmith> so 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:58 <gmann> rosmaita: and it is for consistency not like we have to bump due to incompatibility for cinder, python-cinderclient Yoga version
15:36:21 <rosmaita> well, it's two things
15:36:27 <dansmith> fungi: version ranges you mean right?
15:36:28 <fungi> dansmith: even that they work with "current" os versions, rather than whatever just got published to pypi yesterday
15:36:35 <yoctozepto> well, bumping regularly makes sense; though bumping to always-latest might not be
15:36:38 <rosmaita> first is that i don't like listing minima that we haven't been testing with
15:36:41 <dansmith> fungi: sure, sure
15:36:57 <rosmaita> second is that i like to keep the requirements consistent across all the cinder project deliverables
15:37:22 <gmann> so that is about testing lower constraints right
15:37:29 <yoctozepto> gmann: +/-
15:37:41 <yoctozepto> lower-constraints were not really tested well
15:37:43 <dansmith> rosmaita: tbh, having brick's requirements not exactly equal to nova-compute is also as important as cinder/brick right?
15:37:50 <gmann> yoctozepto: yeah. which is always the case
15:37:54 <yoctozepto> my issue is
15:38:08 <yoctozepto> if we are going to get 30% hit on gating capacity
15:38:14 <gmann> min vesions listed in req file is always not known that they work or not
15:38:17 <rosmaita> dansmith: i think it mostly affects nova's lower-constraints job
15:38:19 <yoctozepto> we can't really say let's run devstack job alternatives with l-c
15:38:26 <yoctozepto> also, l-c differ between projects
15:38:36 <fungi> right, 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 changes
15:38:36 <yoctozepto> so with our coinstallability requirement
15:38:39 <yoctozepto> we cannot do this
15:38:47 <gmann> true
15:38:54 <dansmith> rosmaita: 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 together
15:38:57 <yoctozepto> (I don't like this requirement and think it's wrong nowadays but I understand people got used to it)
15:39:12 <gmann> main question is "what we want to convey with requirements.txt file" ?
15:39:14 <yoctozepto> and yeah, cases like dansmith mentioned
15:39:20 <rosmaita> gmann: ++
15:39:27 <yoctozepto> where openstack controls both the caller and the callee
15:39:27 <jungleboyj> gmann: ++
15:39:34 <yoctozepto> gmann: ++
15:39:46 <yoctozepto> what we want and what we can, basically
15:40:01 <fungi> the "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 environment
15:40:03 <gmann> and having them inconsistent make then more wrost, like one case dansmith mentioned
15:40:38 <dansmith> well, with containers those pieces are smaller than all of openstack, which is the case for conventional packages
15:40:48 <yoctozepto> precisely
15:40:49 <dansmith> but, things like brick tie certain pieces together which would otherwise be separate
15:41:02 <dansmith> i.e. cinder and nova, linked through brick
15:41:07 <gmann> I feel it at least (where we cannot test all the cases), making minima consistent with adjacent/used lib make sense
15:41:29 <fungi> also i can't see us telling "traditional distros" to take a hike and stop bothering trying to package openstack
15:41:44 <dansmith> so, what if we tie our maximum to pip or whatever we need, and tie our minimum to ubuntu LTS or LTS-1 ?
15:42:11 <dansmith> meaning 18.04 right now, soon to be 20.04
15:42:19 <gmann> dansmith: you mean for per repo or for all openstack ?
15:42:26 <dansmith> for lower-constraints, effectively
15:42:51 <dansmith> I'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 upgrades
15:43:00 <gmann> but that does not solve the current question from rosmaita. making few adjacent/related lib minima consistent ?
15:43:09 <fungi> that 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:15 <dansmith> well, part of his concern, I think, is that the minima aren't tested
15:43:24 <dansmith> fungi: right
15:43:43 <fungi> so we can't `pip install` the collective set of versions of our dependencies which are listed by those distros
15:43:58 <dansmith> fungi: 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 more
15:45:48 <fungi> i 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 community
15:46:09 <dansmith> yup
15:46:39 <rosmaita> that sounds good to me
15:46:43 <yoctozepto> fungi: ++
15:46:48 <yoctozepto> that's reasonable
15:46:50 <gmann> yeah, we should cleanup l-c completely to make it clear
15:47:04 <dansmith> gmann: wouldn't that be nice :)
15:47:05 <fungi> we 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 flawed
15:47:08 <yoctozepto> and cleanup ranges in requirements.txt gmann
15:47:16 <gmann> yoctozepto: yeah inclduing that
15:47:20 <yoctozepto> I'm all in
15:47:29 <yoctozepto> that's a clear message
15:47:33 <yoctozepto> plus a resolution
15:47:37 <dansmith> so we have no l-c or u-c, just reqs.txt?
15:47:41 <yoctozepto> and we close this chapter
15:47:51 <yoctozepto> dansmith: just reqs and u-c picking tested versions
15:47:59 <rosmaita> i think we still need u-c
15:48:03 <fungi> i think we still need the upper constraints becaus ethat's how we pin our testing environments
15:48:10 <gmann> I will add this to PTG to discuss it more and find some clear way instead of current mixed one.
15:48:13 <rosmaita> fungi: ++
15:48:14 <dansmith> I don't see why we need both
15:48:28 <fungi> yes, it needs much more discussion with a broader cross-section of the community
15:48:32 <gmann> yeah if l-c goes then we do not need both
15:48:34 <yoctozepto> dansmith: we need upper boundary for testing coinstallability
15:48:48 <yoctozepto> reqs specify which of those are used by a project
15:48:51 <dansmith> yoctozepto: we don't if we're not promising*any* ranges
15:49:16 <fungi> dansmith: i think we can drop version numbers from requirements.txt in projects, probably, but that too will need some experimenting
15:49:17 <dansmith> yoctozepto: we could just have g-r, which is effectively u-c today as our requirements I think
15:49:21 <gmann> #action gmann to add topic "lower bound versions direction as community" in PTG
15:49:44 <yoctozepto> dansmith: ugh, no idea how well g-r behaves nowadays
15:49:52 <yoctozepto> I think it's not used in many places
15:49:59 <yoctozepto> anyway, something to experiment with
15:50:07 <dansmith> I think we're mincing words, but yeah
15:50:17 <fungi> i can exlpain the current state of global requirements management in detail, but not within the time remaining for this meeting
15:50:24 <spotz> rosmaita: Is this something you need decided on before PTG or are you good with gmann's action item?
15:50:51 <rosmaita> i am ok with ptg discussion, especially since
15:51:03 <rosmaita> it appears everyone is OK with what i did with os-brick
15:51:09 <jungleboyj> ++
15:51:10 <rosmaita> and plan to do with cinderclient and cinder
15:51:14 <gmann> rosmaita: anything blocking until we discuss in PTG?
15:51:46 <spotz> ++
15:51:47 <rosmaita> no, i just wanted to get  a sense of whether this issue was considered a problem by the general community
15:51:50 <gmann> rosmaita: yeah os-bricks way seems fine but I will say to do for cinder or client, let's wait for PTG outcome?
15:52:19 <gmann> yeah it is surly an open confusion for long.
15:52:40 <rosmaita> i guess i could leave those alone
15:53:01 <rosmaita> except for oslo.vmware
15:53:15 <gmann> ok
15:53:38 <gmann> anything else?
15:53:45 <rosmaita> ok, i will be less aggressive with the requirements for cinderclient and cinder
15:53:49 <rosmaita> no, that's all from me
15:54:07 <rosmaita> thanks everyone
15:54:20 <gmann> rosmaita: thanks for brining it, let's see if we can find some permanent solution this time
15:54:23 <gmann> #topic Open Reviews
15:54:35 <gmann> #link https://review.opendev.org/q/projects:openstack/governance+is:open
15:54:39 <gmann> open reviews
15:54:51 <dansmith> gmann: should I be rollcall vote'ing on my own resolution?
15:55:09 <gmann> dansmith: yes, you can
15:55:31 <gmann> dansmith: I saw one question there.
15:55:38 <dansmith> okay so we're at 4 +1s there and several +1s from the community..
15:56:00 <dansmith> yep, -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:23 <gmann> yeah, you replied, i did not see
15:56:27 <yoctozepto> well, zigo raised the just-discussed issue as well so
15:56:40 <gmann> number of votes are good, we just need to wait for 3 more days as per formal-vote process
15:56:54 <dansmith> okay, that was my next question, thanks :)
15:57:03 <belmoreira> we also discuss it in the previous video meeting for this topic
15:57:16 <gmann> yeah
15:57:44 <belmoreira> this is an important change. It would be great to have all the TC represented in the change
15:58:07 * jungleboyj has a tab open
15:58:15 * yoctozepto has a tab open too
15:58:26 * yoctozepto expects a RV+1 tbh
15:58:40 <gmann> it is mergeable on 28th, I will do
15:59:02 * spotz has lots of tabs
15:59:05 <gmann> yeah, the current TC votes as per on 28th
15:59:11 <dansmith> we should also get belmoreira's as soon as it's allowed, before he disappears, IMHO
15:59:19 <dansmith> I mean.. "disappears" :)
15:59:26 <yoctozepto> yeah, I was about to ask
15:59:30 <yoctozepto> if you plan a kidnapping
15:59:39 <dansmith> yoctozepto: too soon
15:59:42 <yoctozepto> yeah
15:59:47 <dansmith> :P
15:59:47 <belmoreira> :)
15:59:51 <gmann> :)
15:59:58 <gmann> other thing i pushed zed testing runtime #link https://review.opendev.org/c/openstack/governance/+/830454
16:00:22 <gmann> keeping ubuntu20.04 as 22.04 is planned to release on 21st April which is after Zed cycle start
16:00:26 <gmann> any concern on that?
16:00:34 <yoctozepto> no, we can update later
16:00:34 <dansmith> I need to re-+1 both of those
16:00:40 <yoctozepto> well, "you" can :D
16:00:50 <gmann> yoctozepto: humm, I am thinking not to do.
16:00:58 <gmann> and consider in AA ?
16:01:10 <spotz> Are we tested on it?
16:01:11 <yoctozepto> gmann: we/you can query the community
16:01:20 <dansmith> yeah, IMHO, we should not shift the Z reqs late and just call this good
16:01:20 <yoctozepto> and, well
16:01:22 <gmann> spotz: on 22.04 ?
16:01:23 <yoctozepto> if QA can handle this
16:01:29 <gmann> dansmith: yeah
16:01:33 <yoctozepto> I would stay on 20.04 too
16:02:01 <gmann> yoctozepto: I do not think so, I am doing mostly the migration for last few times and it involve lot of testing
16:02:17 <yoctozepto> gmann: yeah, I know the drill
16:02:28 <spotz> gmann: teah
16:02:29 <yoctozepto> and can't help nowadays
16:02:47 <gmann> spotz: that is not yet, as not released officially
16:02:48 <yoctozepto> so let's not ruin Zed because of this
16:03:12 <yoctozepto> we're past time
16:03:13 <gmann> yeah, lot of other things also we need to finish like RBAC etc
16:03:14 <yoctozepto> OH NO
16:03:26 <gmann> anyways we are out of time, please review and add you vote there
16:03:33 <yoctozepto> thanks gmann
16:03:35 <yoctozepto> take care
16:03:44 <jungleboyj> gmann:  Thanks!
16:04:02 <gmann> that is all for today, next meeting will be video call. I will add link there
16:04:07 <gmann> thanks all for joining
16:04:10 <gmann> #endmeeting