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