| gouthamr | hi tc-members: any more objections in unblocking this for the freezer team: https://review.opendev.org/c/openstack/governance/+/914911 ? | 01:02 |
|---|---|---|
| opendevreview | Brian Haley proposed openstack/project-team-guide master: Improve terminology in project-team-guide tree https://review.opendev.org/c/openstack/project-team-guide/+/917864 | 16:17 |
| tkajinam | gmann, (I could not find the appropriate channel) I don't know if we really have to enforce min bump for all versions to drop old exclude because min version bump has tradeoff. Since some projects already bare cleanup IMO the decisions would be dependent on project. | 17:20 |
| tkajinam | I'm happy to update these in case min bump sounds better for a specific project but I'm hesitant to update all of theses if a specific project team is happy with bare removal | 17:21 |
| gmann | tkajinam: requirements.txt is the best effort to keep min and working version up to dated. As you know, those are not tested also. we should not remove the info of what broken versions we have so that people can avoid installing them | 17:21 |
| tkajinam | so do you want me to submit 30 follow-ups to bump mins in all repos which already merged the cleanup ? | 17:22 |
| gmann | tkajinam: I do not think it is project wise choice it is matter of how close they are correct | 17:22 |
| tkajinam | I can do it technically but I don't know if bumping min to exclude 2+ years old version is really worth paying effort | 17:22 |
| gmann | we should not have removed the known breaking version at first place itself | 17:22 |
| tkajinam | the requirement files in each project hasn't been sync really these days. for example core global-requirements contains more know broken versions but these are not actually synced | 17:23 |
| gmann | I am sure someone will come and say your doc requirements.txt say sphinx 2.1.0 can bt used but it does not work | 17:23 |
| tkajinam | 2.1.0 was released in Jun 2, 2019. Should we really care people trying to use such ancient versions ? | 17:24 |
| gmann | tkajinam: yeah but we should not make it more worst. as those are not tested, we should be more clear here than less clear. if that is being tested and verified one that it could be fine | 17:24 |
| JayF | You're both kinda right? I'd posit that getting those conversations to happen and getting those excludes in the global requirements would be a benefit of this effort, yes? | 17:24 |
| gmann | tkajinam: why not, if we say min version we support is 2.0.0 then we cannot say do not try 2.1.0. that is why bupming it to >2.1.0 is right one | 17:25 |
| gmann | and as lower constraints testing has been gone, we should have known working version info in requirements.txt otherwise I do not see any value of having min version there at all | 17:26 |
| tkajinam | I'm very skeptical that 2.1.0 works now. yes it may loose our old old knowledge but I don't know keeping it is really useful nowadays | 17:27 |
| tkajinam | given the tradeoff we have to pay to update min properly | 17:27 |
| gmann | when we removed the lower constraint testing, we had debate on keeping these min version in requirements.txt file and we did note remove it from there to have a correct upto dated info. otherwise we can have this file same as g-r | 17:28 |
| tkajinam | I ended up opening 20+ pypi pages to find the "next version to the known bad version". I could do it for a few repos but doing it to all repos is a bit of work, you know | 17:28 |
| JayF | tkajinam: with my Ironic hat on; I trusted our CI to validate that none of the bad versions were getting installed for our testing ... I think that's a reasonable approach | 17:28 |
| gmann | tkajinam: we have those breaking changes excluded in that file so that info about breaking changes are gone if we do not bump min vesion to the one which exclude the breaking one | 17:29 |
| tkajinam | JayF, now that's guaranteed by upper-constraints | 17:29 |
| JayF | Information is never lost in git, though. It's in the repo even if not on HEAD. | 17:29 |
| gmann | I will prefer we keep those as it is if not excluding the breaking one in min version | 17:29 |
| JayF | tkajinam: that was the assumption I worked under generally :) | 17:29 |
| gmann | we do not test min version anywhere | 17:29 |
| gmann | I am ok to have that g-r change but requirements.txt file should not remove the known breaking version exclusion we already have | 17:30 |
| tkajinam | maybe we should stop comparing excludes if these are not maintained in g-r | 17:31 |
| tkajinam | that's the easiest approach than updating requirement files in each repos | 17:31 |
| tkajinam | for every cleanup | 17:31 |
| tkajinam | frickler, ^^^ | 17:31 |
| tkajinam | unless we care a smart tool to bump min properly. | 17:32 |
| gmann | I am not sure but that is project best effort that if they know any breaking version then it is documented in requirements.txt | 17:32 |
| gmann | g-r is one thing but requirement file with extra info on min version and excluding breaking versions on project side is another info for package maintainers | 17:33 |
| tkajinam | in the past bad versions were kept in global req and was synced to each repos. since that sync was stopped, know bad versions are maintained per project and we really don't have very good reason to force consistency of excludes IMO | 17:37 |
| tkajinam | if we want to apply different policy about maintaining bad versions/min in g-r and individual repo | 17:37 |
| gmann | IMO, we should otherwise our requirements.txt files will be confusing things for them. which tell them wrong info about min version | 17:38 |
| tkajinam | min version itself works. the problem is that there are a few versions newer than min which may not work | 17:38 |
| clarkb | is the problem that distro packagers have to now scan all requirements.txt to make sure the distro version doesn't conflict with any known bad version? | 17:38 |
| clarkb | I wonder if we can just try to keep that info in global requirements as much as possible even if it isn't synced. I guess this would always run the risk of being incomplete | 17:39 |
| gmann | tkajinam: I thnik min versions means any version above this version works fine until the upper constraints | 17:39 |
| gmann | i am not sure distro packagers scan all but from debian we receive feedback that they wanted to keep min version info in requirements.txt even though they wanted to test those also. | 17:40 |
| gmann | my main point here is do not remove the already known breaking version info from there. if we do not improve those or keep up to dates it is fine but do not remove existing known breaking versions. that is why bumping min should be careful so that we do not lose that info | 17:42 |
| tkajinam | https://review.opendev.org/c/openstack/requirements/+/917869 | 17:44 |
| tkajinam | maybe this is the right step given these feedbacks then. | 17:45 |
| tkajinam | clarkb, IIUC excludes in g-r and ones in individual repos are not fully synced but the excludes in individual repos should be listed in g-r | 17:47 |
| tkajinam | clarkb, so g-r was the place where all excludes were maintained. projects can pick up some of these and add them to their own requirements | 17:47 |
| tkajinam | that's also the reason why we are facing the broken requirements-check job now | 17:48 |
| gmann | we can still remove the excludes if we bump the min version higher than the excludes one right? that fix the things and does not require g-r revert | 17:48 |
| tkajinam | we can do but I don't know how much gain we may have after I learned how much effort we may need to react on clean up. | 17:49 |
| gmann | ok but that is same as existing proposed changes we just need to update the min version making sure they are higher than excluded one | 17:51 |
| tkajinam | I don't know if that is same | 17:55 |
| tkajinam | now we have two options basically | 17:55 |
| tkajinam | 1. revert that g-r cleanup then no change is needed in req files in each repo | 17:56 |
| tkajinam | 2. keep that g-r cleanup and remove old versions and bump min version to exclude the bad versions | 17:56 |
| tkajinam | my point is 2 requires really large effort while it does not really provide much benefit. I could accept the tradeoff if we don't care about min bump but if we need it then it really requires non-automated effort (unless someone develops a tool) | 17:58 |
| tkajinam | which I don't think really worth paying effort for | 17:58 |
| tkajinam | ok tonyb approved that revert | 17:59 |
| frickler | IMHO listing broken versions in requirements would only be worthwhile if we made an attempt for these to be complete, which given the rate of u-c updates we decidedly don't do currently | 18:01 |
| tonyb | tkajinam: We can for sure fixup the tooling. But as you point out there is effort there and the quick revert is IMO the best near term fix | 18:01 |
| frickler | so I am very much in favor of removing old excludes. we could discuss whether 2 years is not enough and bump to 3 or 5 years if poeple prefer | 18:01 |
| frickler | and I also don't think enforcing projects to bump minor constraints is helpful. if nova wants to do it, let them, if designate doesn't, fine too | 18:02 |
| tonyb | frickler: I think we need as a minumum to ensure that removing them from g-r doesn't break the requirements-check jobs of $lots of repos but yes I think removing the old list is a good idea | 18:02 |
| gmann | whatever way we prefer but we should have correct information about min version. not excluding the breaking one in min version is not right as it tells that the breaking version can work. that is why my concern on those changes. | 18:04 |
| frickler | well I do think that the reqs-check job enforcing the drop of old excludes to be mirrored by projects is a good idea actually | 18:04 |
| gmann | existing info may not be up to dated but at least correct | 18:05 |
| frickler | gmann: we do not have correct information about min versions anyway, we don't test it | 18:05 |
| frickler | gmann: with your reasoning, we should only allow versions in u-c and exclude everything else | 18:05 |
| gmann | yeah but that is best effort by project team to keep them up to dated/correct. current proposed one is making it more wrong | 18:05 |
| frickler | I don't agree, it does expect on what information you expect to see in a projects reqs.txt | 18:06 |
| gmann | frickler: no, I am saying best effort to keep min version as correct. at least do not update them to incorrect info | 18:06 |
| frickler | dropping min version completely isn't more wrong than having some untested guess of what could be a min version | 18:07 |
| fungi | i doubt distro packagers care about the excludes in our reqs/constraints. but you could always ask them | 18:07 |
| fungi | their primary purpose has always been to temporarily fix our upstream testing until newer versions of deps get released | 18:08 |
| gmann | For example, in this change, does not it say sphinx 2.1.0 will work where we had info about this version was broken ? https://review.opendev.org/c/openstack/designate/+/917579/1/doc/requirements.txt#b1 | 18:08 |
| frickler | iiuc zigo already responded yesterday stating they're ok with the latest cleanup | 18:08 |
| fungi | distro packagers are going to generally be backporting fixes to the versions they ship regardless, and so aren't going to ship a "broken" dependency in that sense | 18:08 |
| gmann | I am ok to remove the min version itself form requirements.txt which we tried earlier also but could not do as distro packagers need them | 18:09 |
| frickler | I don't think anyway needs min versions that are 5 years old. we do need them when projects actually require some recent versions, like < 2y old | 18:10 |
| gmann | or keep them as it is and keep updating them to correct one. but making them more wrong is my concern. | 18:10 |
| frickler | s/anyway/anyone/ | 18:10 |
| gmann | sure, I am ok to bump those my concern only is to bump them to excluding the broken versions we know already | 18:11 |
| tkajinam | I still prefer we leave it to project's decision as we don't really have strict policy about low-req since we made it best-effort | 18:13 |
| gmann | not sure why "sphinx>=2.1.1" is not the right way than "sphinx>=2.0.0" where we know 2.1.0 is broken version. former one make sure we remove excludes and also bump min version so that info about broken version are correct | 18:13 |
| tkajinam | gmann, I don't disagree with the idea but I'm saying that's not an easy update atm | 18:13 |
| tkajinam | because you have to find that sphinx 2.1.1 is the next version of 2.1.0 to make that update correctly | 18:14 |
| JayF | I think I agree about the ideal case, gmann, but I also agree with tkajinam not wanting to do *even more* than is already being done across so many repos... | 18:14 |
| JayF | this is why I'm OK with a solution that might push a little more effort down on distro packagers (even though I'm not convinced this will), and if it's too onerous they cna push back | 18:15 |
| JayF | but at some point we run out of hours in the day or other things suffer from trying to cover all the edges | 18:15 |
| gmann | I think doing it in-progress one should be doable and we can leave the one already merged. most of the deps are common in many projects for example sphinx, oslo lib etc | 18:16 |
| gmann | tkajinam: do you see many different deps across projects to determine their min version ? If so I can help you for those in gerrit comment and you can update. If you want to at least fix the not merged one | 18:18 |
| gmann | but up to you if you want to spend more time on those and as revert is also approved | 18:18 |
| tkajinam | gmann, some of these are common but not totally same. I saw different excludes for the same library | 18:18 |
| gmann | ok | 18:19 |
| tkajinam | gmann, it's technically doable, yes, if some one will pay effort for it. that's my main point. | 18:21 |
| tkajinam | I'm leaving now. the remaining patches may not be merged with -1. we can resume discussion later when we revert the revert | 18:23 |
| gmann | tkajinam: ack, yeah let's discuss if revert-revert is happening. it might be late for you, take rest. | 18:26 |
| fungi | just to be clear, the origin of this discussion was cleaning something up in openstack/requirements broke requirements sync jobs for some projects? if so, i thought we had declared that those were no longer necessary to run and could be removed | 19:00 |
| frickler | fungi: no, the cleanup broke the reqs-check job which complains if a project has an exclude that isn't recorded in g-r | 19:31 |
| frickler | we could though consider to relax that part of the check | 19:31 |
| frickler | but maybe that would really be an issue for distros then | 19:32 |
| fungi | got it, there were versions in some projects that weren't allowed but were going to be allowed according to the changed global-requirements.txt | 19:34 |
| fungi | i was worried that some individual projects were still running the job that used to check that the versions they specified in requirements.txt matched verbatim what's in global-requirements.txt, which hopefully they've not been doing for years now | 19:36 |
| opendevreview | Merged openstack/governance master: Add frrouting route under OpenStack-Ansible governance https://review.opendev.org/c/openstack/governance/+/910019 | 22:07 |
| opendevreview | Merged openstack/governance master: Transition Freezer project to DPL https://review.opendev.org/c/openstack/governance/+/914911 | 23:05 |
| opendevreview | Merged openstack/governance master: Add openstack-helm-plugin git repository https://review.opendev.org/c/openstack/governance/+/916009 | 23:37 |
Generated by irclog2html.py 2.17.3 by Marius Gedminas - find it at https://mg.pov.lt/irclog2html/!