15:00:11 <mnaser> #startmeeting tc
15:00:12 <openstack> Meeting started Thu Jan 14 15:00:11 2021 UTC and is due to finish in 60 minutes.  The chair is mnaser. Information about MeetBot at http://wiki.debian.org/MeetBot.
15:00:12 <mnaser> #topic rollcall
15:00:13 <openstack> Useful Commands: #action #agreed #help #info #idea #link #topic #startvote.
15:00:16 <openstack> The meeting name has been set to 'tc'
15:00:22 <gmann> o/
15:00:25 <belmoreira> o/
15:01:09 <ricolin> o/
15:02:57 <jungleboyj> o/
15:04:20 <mnaser> hrm, i guess we can still meet and don't necessarily require a quorum?
15:04:36 <jungleboyj> Ok with me.
15:04:53 <fungi> technically it won't count as a "meeting" for purposes of satisfying the bylaws and charter requirements, but as long as it's not every time it's fine
15:04:55 <gmann> 6 are here if knikolla is still here
15:05:04 <knikolla> o/
15:05:11 <jungleboyj> :-)
15:05:13 <mnaser> fungi: we'll need 1/4 times a month to hit quorum ;P
15:05:19 <mnaser> i'll take my chances ha
15:05:27 * knikolla lost track of time
15:05:28 <fungi> quorum is mostly important if binding decisions are going to be made *in* the meeting, which the tc doesn't do these days thanks to gerrit
15:05:40 <mnaser> #topic Follow up on past action items
15:05:51 <mnaser> diablo_rojo complete retirement of karbor
15:06:32 <mnaser> i think that's mostly been done, we just need https://review.opendev.org/c/openstack/project-config/+/767057 rebased
15:06:37 <mnaser> and then we can merge the governance patch
15:06:45 <mnaser> i'll keep it on the list till next week to keep following up with it
15:06:51 <mnaser> #action diablo_rojo complete retirement of karbor
15:07:01 <mnaser> mnaser submit a patch to officially list no community goals for X cycle
15:07:10 <mnaser> i submitted a patch and started getting feedback which is good :)
15:07:13 <jungleboyj> ++
15:07:17 <jungleboyj> Thanks for doing that.
15:07:26 <mnaser> dont think we need that as an action item to follow up anymore, this lives in gerrit now to continue
15:07:40 <gmann> yeah, that works
15:07:42 <mnaser> diablo_rojo reach out to SIGs/ML and start auditing states of SIGs
15:08:12 <mnaser> we have a topic for this that we can re-add the action item to
15:08:45 <mnaser> diablo_rojo update resolution for tc stance on osc -- that was done and looks like we're progressing on reviews, no need for an action item imho, as it's an open review / disucssion
15:09:23 <mnaser> gmann continue to audit tags + outreach to community to apply for them <= we can keep that for the discussion later too imho
15:09:25 <gmann> yeah close to merge once dansmith comments are resolved for CI things
15:09:29 <gmann> yeah
15:09:40 <mnaser> #topic Write a proposed goal for X about stabilization/cooldown (mnaser)
15:09:42 <dansmith> o/
15:09:54 <mnaser> #action mnaser to remove proposed goal topic from agenda
15:10:08 <mnaser> i think this mostly continues to live inside gerrit imho
15:10:36 <mnaser> (going through those quickly to have more time for the later topics :])
15:10:37 <jungleboyj> Makes sense.
15:10:46 <mnaser> #topic Audit SIG list and chairs (diablo_rojo)
15:11:01 <mnaser> no progress update, we'll keep an action item to keep up with it
15:11:04 <mnaser> #action diablo_rojo reach out to SIGs/ML and start auditing states of SIGs
15:11:18 <jungleboyj> Kind of seems like we need diablo_rojo for all of this.  :-)
15:11:19 <mnaser> #topic Annual report suggestions (diablo_rojo)
15:11:33 <gmann> ricolin also mentioned to help on SIG audit in previous discussion, not sure if he has some updates to share
15:11:36 <ricolin> diablo_rojo let me know if you need help on SIGs auditing
15:12:00 <mnaser> #action mnaser remove annual report suggestions from agenda
15:12:13 <mnaser> (its getting drafted so too late to make changes so we can close that out)
15:12:20 <ricolin> gmann, I didn't get anything on that yet
15:12:22 <mnaser> and ricolin that's awesome, i think it would be good to connect with kendall on that
15:12:29 <gmann> ok
15:12:49 <ricolin> mnaser, sure, or I can just take that action if diablo_rojo is not available for now
15:12:50 <mnaser> #topic Add Resolution of TC stance on the OpenStackClient (diablo_rojo)
15:13:07 <mnaser> ricolin: i will leave it for you and diablo_rojo to figure out how you want to sort that out together :)
15:13:21 <mnaser> #link https://review.opendev.org/c/openstack/governance/+/759904
15:13:58 <mnaser> i know dansmith had some comments on having the CI / docs language in there
15:14:07 <mnaser> which i think make sense to me
15:14:08 <dansmith> yeah
15:14:19 <dansmith> I think it just got lost in all the worddansmithing
15:14:28 <mnaser> dansmith: do you think you could respin that with some of the wording ideas you had? i think kendall would probably appreciate that help
15:14:29 <gmann> yeah, good to mention that too
15:14:32 <mnaser> _if_ you can :)
15:14:35 <dansmith> sure I can
15:14:47 <mnaser> that would be great and helpful and then we can help land it
15:15:12 <dansmith> I know diablo_rojo_phon is like super defensive of turf, so I didn't want to run afoul of any good neighbor rules
15:15:25 <mnaser> ahaha , i don't think so =P
15:15:28 <dansmith> hehe
15:15:51 <mnaser> #action dansmith update osc change to include ci/docs commentary
15:16:04 <mnaser> #topic Audit and clean-up tags (gmann)
15:16:28 <gmann> bumped the email with ptl tag for API interoperability tag
15:16:38 <gmann> #link http://lists.openstack.org/pipermail/openstack-discuss/2021-January/019814.html
15:16:50 <gmann> let's see how many projects start applying it
15:17:18 <gmann> nothing else to update on this.
15:17:33 <mnaser> ok, thank you for following up on this
15:17:53 <mnaser> i'll rename this topic
15:18:08 <mnaser> #topic infra-core additions (was Farewell Andreas) (diablo_rojo)
15:18:49 <mnaser> #link https://review.opendev.org/q/project:openstack/project-config+is:open
15:18:56 <mnaser> the repo seems to be quiet and there isn't really a backlog (yet)
15:19:12 <fungi> i've been trying to pay a little more attention to changes in there
15:19:34 <gmann> yeah few of them can be merged for label things which just lost somehow
15:19:38 <fungi> mainly to make sure folks don't wait on simple requests like project creation or job shuffling
15:19:45 <mnaser> thanks fungi -- i should try to make a bit of an effort, feel free to ping me for reviews anytime
15:19:49 <gmann> I will also try to review those today
15:19:53 <fungi> gladly, thanks!
15:20:27 <fungi> we should also bring up this topic in the opendev infrastructure meeting, maybe get it on the agenda for next tuesday
15:20:30 <mnaser> i don't know if there is anything actionable yet
15:21:05 <mnaser> but maybe as we get more into the year things start picking up again
15:21:20 <fungi> we can at least quickly mention that it's worth keeping an eye out for any frequent config reviewers who could help us merge stuff if they had +2 permissions
15:21:37 <openstackgerrit> Dan Smith proposed openstack/governance master: Add Resolution of TC stance on the OpenStackClient  https://review.opendev.org/c/openstack/governance/+/759904
15:21:38 <fungi> but i agree, that's probably not the case just yet
15:21:42 <dansmith> ignore this ^
15:21:57 <mnaser> agreed
15:22:27 <mnaser> #action mnaser add openstack/infra-core as discussion topic in opendev meeting
15:22:57 <mnaser> i say we can drop the topic (for now).. and we can agree to work with opendev if we start to develop some sorts of a backlog
15:23:07 <fungi> get it onto the agenda before monday if possible, because clarkb usually announces the agenda on the ml a day ahead
15:23:14 <gmann> make sense
15:23:19 <mnaser> ack, i'll try to get it done today
15:23:19 <ricolin> +1
15:23:23 <fungi> thanks!
15:23:42 <mnaser> i'll keep it here so i have a chance to update the tc on it next week
15:23:52 <mnaser> #topic Dropping lower-constraints testing from all projects (gmann)
15:24:38 <gmann> yeah this is something projects asked to TC for consensus and direction for all proejcts
15:24:50 <gmann> #link http://lists.openstack.org/pipermail/openstack-discuss/2021-January/019672.html
15:24:57 <gmann> this is ML with other ML thread link too
15:25:12 <gmann> oslo, ironic, and i thin neutron already started dropping l-c job
15:25:20 <gmann> #link https://review.opendev.org/q/topic:%22oslo_lc_drop%22+(status:open%20OR%20status:merged)
15:25:31 <slaweq> gmann: neutron only for stable branches for now
15:25:39 <gmann> slaweq: i see, thanks
15:25:47 <slaweq> we discussed that in our team meeting and decided to go that way for now
15:25:49 <gmann> nova also made them n-v for stable branch
15:27:21 <mnaser> hrm
15:27:32 <gmann> l-c testing is not part of PTI i think but we should provide some direction here for consistency testing and providing lower bound to package maintainer or so
15:27:44 <knikolla> keystone has dropped l-c for now too.
15:28:05 <gmann> ah did nt know about keystone, thanks knikolla  for update
15:28:55 <gmann> I do not have any package maintenance experience so do not know how much helpful current l-c file is for them
15:29:10 <openstackgerrit> Dan Smith proposed openstack/governance master: Add Resolution of TC stance on the OpenStackClient  https://review.opendev.org/c/openstack/governance/+/759904
15:29:42 <mnaser> honestly it sounds like our current l-c were not exactly testing in a valid way
15:29:59 <gmann> yeah
15:30:04 <fungi> i doubt any distro packagers directly rely on the lower-constraints.txt files in projects for anything, but they may indirectly rely on our lower bounds checking to ensure that our projects actually work with the minim versions of dependencies we list in our requirements.txt files
15:30:26 <mnaser> maybe if apevec is around or can ping someone from the rdo team to answer ^
15:30:39 <fungi> so if someone can work out a consistent, deterministic means of testing lower bounds then it might be of some benefit to package maintainers
15:30:51 <gmann> true
15:31:12 <knikolla> an automated way to keep those up to date too, would be quite helpful.
15:31:12 <fungi> but i doubt jobs which aren't actually testing our lower bounds (like the l-c jobs before pip's dep solver got smart enough to tell us) were doing anyone any good
15:31:29 <mnaser> fungi: which further proves that they weren't being consumed by distros
15:31:34 <mnaser> because otherwise they'd all be broken
15:31:38 <mnaser> (a long time ago)
15:32:38 <apevec> fungi, we don't rely on lower-constraints
15:32:53 <fungi> htanks for confirming!
15:32:57 <fungi> er, thanks
15:33:00 <mnaser> so that rules out rdo, so does debian/ubuntu/opensuse rely on it is the remaining question
15:33:28 <dansmith> well, whats-his-face chimed in right?
15:33:38 <fungi> zigo was the only package maintainer i recall speaking up on the discuss ml asking us to keep testing our minimum versions
15:33:45 <dansmith> yar, zigo
15:33:49 <gmann> yeah
15:34:01 <mnaser> right, but i don't know if that was "we use it" or "it is something that's nice to have"
15:34:03 <fungi> but didn't directly acknowledge that the jobs never actually tested what folks thought they were testing to begin with
15:34:10 <rosmaita> another question is whether there would be a problem if we keep the minima in requirements as close to the upper-constraints as possible?
15:34:16 <apevec> we track u-c and keep our deps on that upper end, doing period sync e.g. https://review.rdoproject.org/r/#/c/31545/
15:34:34 <rosmaita> my understanding of the l-c was that it gave packagers a wider range to choose from to satisfy several projects
15:34:34 <mnaser> i just pinged jamespage in #openstack-charms to hear if they use it, i suspect they don't
15:35:01 <mnaser> i think the only reason why debian is concerned is because it ships _as part of debian_ and not some extra repo so that might be useful
15:35:08 <mnaser> uca/rdo all ship diffferent repos with all their own packaging
15:35:15 <gmann> this one from zigo http://lists.openstack.org/pipermail/openstack-discuss/2021-January/019684.html
15:35:17 <fungi> rosmaita: correct, or rather us keeping looser minimums gave them that option
15:35:18 <mnaser> so they just ship with upper constraints
15:36:00 <knikolla> also, the tests in the respective tox.ini files use upper contraints
15:36:35 <mnaser> yup
15:36:44 <gmann> knikolla: expect l-c tox env, rest all yes use u-c
15:36:48 <rosmaita> yes, most testing (except for the l-c job) is being done with versions close to the upper-constraints
15:36:55 <rosmaita> what gmann said
15:37:09 <knikolla> but the l-c job also only tests that the dependencies are installed, and doesn't run the actual tests, right?
15:37:22 <rosmaita> runs unit tests, i believe
15:37:22 <fungi> django is the perennial example. horizon is only one of many bits of software in the broader ecosystem which relies on django. it's easier on distros if most projects can use a common version of django so that they don't have to carry multiple django releases in the distro. if we aggressively bump our django minimum in horizon, *that's* what makes their job harder (as does not aggressively raising our
15:37:24 <fungi> max cap on django in horizon)
15:37:40 <mnaser> getting a more detailed confirmation but from #openstack-charms: "<jamespage> mnaser: I don't think so - I believe we still focus on alignment with upper-constraints"
15:37:42 <gmann> yes unit test does not actually test for exact lower bound and all
15:38:14 <mnaser> so that's two packagers that don't care about them
15:38:36 <mnaser> <coreycb> mnaser: thanks for checking, we try to align as best we can with upper-constraints. I don't think we ever look at lower-constraints.
15:38:45 <mnaser> so that leaves debian and suse
15:39:03 <mnaser> for suse we can discuss in the next point, and debian perhaps we can reach out to zigo and ask if that's actually used in some sort of job?
15:39:11 <mnaser> and if no one uses it...
15:39:24 <gmann> yeah, next topic is for suse testing support
15:39:50 <fungi> what was previously happening with the l-c jobs and older pip is that it was installing the exact versions listed in lower-constraintx.txt, but not all the transitive dependency set was necessarily listed there, and pip was also potentially installing versions of packages which conflicted with minimum or max cap requirements in other dependencies (so could have been subject to subtle incompatibility
15:39:52 <fungi> bugs not apparent in unit testing, for example)
15:40:13 <mnaser> could someone reach out to the ML and check if zigo can confirm if its a "nice code quality thing" or "we actually have things that actively use them" ?
15:40:25 <mnaser> for suse, we can leave that for the next point
15:40:45 <rosmaita> fungi: exactly, that is my worry about having too wide a gap between the minima in requirements and upper-constraints
15:41:05 <gmann> mnaser: sure, i can check that
15:41:25 <mnaser> #action gmann follow-up with zigo if debian uses l-c
15:41:50 <mnaser> IMHO, if no one uses it, we can drop it, one less thing for us to worry about that is of no benefit (other than mostly for packagers)
15:41:58 <mnaser> and they don't care about it, we should invest our time elsewhere :)
15:42:12 <mnaser> (and also, adding that it also wasn't reliable)
15:42:19 <rosmaita> ok, so the advantage of the l-c job is that it (sort of) kept us honest about the minima in our requirements
15:42:30 <mnaser> rosmaita: correct!
15:42:34 <rosmaita> but if we are aggressive about keeping the requirements updated, that won't be a problem
15:42:44 <mnaser> but most packagers don't seem to rely on it and ship upper-constraints anyways
15:43:27 <rosmaita> so it sounds like updating requirements to pip freeze at milestone-3 is a good idea?
15:43:28 <mnaser> so they're always shipping the upper-constraints (which makes sense, cause that's also what openstack upstream ci tests with, minimize any chances of incompatibilities)
15:44:01 <mnaser> not necessarily, because we have no versions for the msot part in reqs, and upper-constraints is the upper boundary
15:44:33 <rosmaita> i mean requirements.txt in each deliverable
15:44:43 <mnaser> upper-constraints is mostly frozen
15:44:53 <mnaser> and all packagers rely on those, so there's no point to freeze it twice
15:45:43 <mnaser> so if glance relies on sqlalchemy, and u-c contains 'sqlalchemy==1.4.0' inside stable/victoria, then rdo will produce python-sqlalchemy-1.4.0 which will be a dependecny of glance package
15:45:51 <mnaser> the same way that our CI would test glance with that version of sqlalchemy
15:47:17 <mnaser> i think we can move onto the next topic with an action item of reaching out to debian and suse will be discussed next and follow up on the progress there
15:47:30 <gmann> and we can remove (after Debian checks) it from master as well as from stable branch,
15:47:31 <rosmaita> ok, so is the consensus that the minimum version of some dependency in requirements.txt for cinder does *not* mean that cinder can actually work with that version?
15:47:51 <fungi> that makes sense when the package is only a dependency of an openstack project, it becomes harder when it's a common dependency of openstack projects and also a lot of non-openstack projects carried by the distro
15:48:00 <rosmaita> so we only need to update minima "on demand", which could force a change to upper-constraints if necessary
15:48:09 <fungi> just "follow our upper constraints" isn't always an option for large distros, unfortunately
15:48:31 <rosmaita> right, so it does sound like some kind of lower bound is useful
15:48:31 <gmann> yeah, follow u-c is much safe and reliable
15:48:35 <mnaser> rosmaita: i would argue that cinder shouldnt pin versions and not worry about minimas and rely on upper constraints
15:48:54 <mnaser> and fungi agreed, but it looks like most popular openstack distros are very much 'fully vendored distros'
15:49:20 <rosmaita> mnaser: that's what happens in practice, my statement is about what expectations people should have in looking at requirements.txt
15:49:37 <fungi> yeah, it's ultimately still up to the package maintainers in distros to solve the problem of getting openstack and gnome and kubernetes and anything else you can imagine co-installable
15:50:00 <fungi> mnaser: i don't know what a "fully vendored distro" is, but you can explain it after the meeting
15:50:18 <gmann> I think rosmaita has good point that if requirement.txt stats the lower bound then it is not so reliable so why having those?
15:50:36 <mnaser> requirements.txt in most openstack projects are meaningless in my experience
15:50:47 <mnaser> if you're not adding upper constraints, you're getting a broken install
15:50:55 <fungi> it's been relied on as a means of triggering pip to upgrade dependencies in an existing environment when updating a package where the lower bound increases
15:51:02 <rosmaita> well, we still need to know when to adjust upper constraints
15:51:17 <mnaser> fungi: oh, i see your point, in case someone doesn't use -U
15:51:25 <rosmaita> happens when cinder says foo>1.2 and u-c has foo==1.1
15:51:36 <fungi> well, even if they do use -U and the upgrade strategy is to only upgrade what's necessary
15:51:43 <fungi> pip has multiple upgrade strategies
15:51:55 <mnaser> right, yes, you'll have to bump u-c first and then 'pin' the newer version afterwards
15:52:14 <mnaser> it sounds like requirements.txt might have been lower-constraints all along :)
15:52:20 <fungi> and people sometimes have to mix distro-supplied python modules with some from pypi, so pip not touching the distro-supplied ones is helpful
15:52:37 <rosmaita> mnaser: i am thinking so too
15:53:01 <mnaser> but maybe not a lower-constraints as much as it is .. lower-requirements
15:53:10 <mnaser> "you need to be newer than this but that's all i'm declaring"
15:53:24 <mnaser> i'd like us to have time for the next subject
15:53:26 <gmann> requirements.txt can match with u-c but not with exact lower bound
15:53:32 <mnaser> so i think we should keep this as an open topic for next week
15:53:50 <rosmaita> sounds good, i think we are approaching some clarity
15:53:53 <gmann> yeah, we will get debian check also meanwhile
15:53:56 <mnaser> yep
15:54:24 <mnaser> thanks for joining rosmaita and apevec, fungi for feedback
15:54:36 <rosmaita> np
15:54:54 <mnaser> #topic Decide on OpenSUSE in testing runtime (gmann)
15:55:27 <mnaser> sad to see and say, but i'm for it
15:55:31 <gmann> opensuse distro job is broken for a month and devstack team is approaching towards removing it #link https://review.opendev.org/c/openstack/devstack/+/769884
15:55:46 <mnaser> there is no investment from the company (as we know this) and none from the community from what i see
15:55:47 <gmann> if we have any maintainer we can add it back anytime
15:55:56 <gmann> yeah
15:56:20 <jungleboyj> They stated that they weren't going to be continuing to support it.
15:56:21 <clarkb> is it broken on master or just stable?
15:56:40 <clarkb> I had sort of been tending to it on master and I thought it was fine there (but also haven't had much time for it recently so maybe that changed)
15:57:00 <gmann> master also
15:57:21 <mnaser> https://zuul.opendev.org/t/openstack/builds?job_name=devstack-platform-opensuse-15
15:57:28 <gmann> https://zuul.openstack.org/builds?job_name=devstack-platform-opensuse-15+
15:57:34 <gmann> ah you are fast :)
15:57:38 <mnaser> :P
15:57:53 <mnaser> https://zuul.opendev.org/t/openstack/builds?job_name=devstack-platform-opensuse-15&result=SUCCESS
15:57:59 <mnaser> the most recent pass was 3rd of december 2020
15:58:05 <gmann> yeah
15:58:39 <clarkb> ah ok so it was working until recently. I wasn't compeltely crazy :)
15:58:50 <mnaser> stable seems to be broken with WARNING: this script has not been tested on opensuse-15.2
15:59:00 <mnaser> master broken with ModuleNotFoundError: No module named 'six'
15:59:07 <mnaser> but i think it's just a matter of extra load on the devstack team
15:59:29 <gmann> yeah and team has really less bandwidth
16:00:11 <mnaser> we will need a change on https://governance.openstack.org/tc/reference/project-testing-interface.html#linux-distributions
16:00:12 <gmann> also in wallaby testing runtime if we remove testing now -https://governance.openstack.org/tc/reference/runtimes/wallaby.html
16:00:15 <mnaser> and maybe for Xena we will drop it from the tested runtimes
16:00:33 <mnaser> should we drop it from https://governance.openstack.org/tc/reference/runtimes/wallaby.html too?
16:00:49 <gmann> I think so if we remove the testing now
16:01:04 <ricolin> I think we should
16:01:05 <mnaser> gmann: how about we make the governance change and if that goes through we merge the devstack one
16:01:20 <ricolin> as it said `Tested` Runtimes for Wallaby
16:01:24 <mnaser> (which it will, but just as part process and the suse job is quickly and quietly failing anyways)
16:01:52 <gmann> sure, from testing runtime and /project-testing-interface.html#linux-distributions both?
16:01:56 <mnaser> i think so
16:02:03 <gmann> ok will do today
16:02:15 <mnaser> any closing thoughts? :)
16:02:20 <ricolin> do we care to have a ML out for this too?
16:03:19 <gmann> before or after moving testing/governance change?
16:03:30 <ricolin> after gov IMO
16:03:31 <gmann> *removing
16:03:59 <ricolin> fine to do it before/after testing
16:04:10 <gmann> yeah i think that will helpful to notify wider people
16:04:51 <fungi> as a wider person, i appreciate notification of things ;)
16:05:12 <gmann> I can put once we finish the changes
16:05:23 <mnaser> thank you gmann
16:05:28 <ricolin> gmann, thx, short notice will do IMO:)
16:05:35 <gmann> sure
16:05:41 <mnaser> #action gmann update supported distros to drop opensuse
16:05:46 <mnaser> i think that's it?
16:05:58 <gmann> yeah.
16:06:03 <mnaser> thank you all :)
16:06:06 <mnaser> #endmeeting