Hi Jeremy, Thanks for your reply. On 1/19/21 4:32 PM, Jeremy Stanley wrote:
On 2021-01-19 08:03:25 +0100 (+0100), Thomas Goirand wrote: [...]
Of course, I'm using upper-constraints too, to try to package them as much as possible, however, the dependencies are expressed according to lower-constraints. [...]
The same lower bounds would also typically be expressed in the requirements.txt file. Presumably you looked there before projects added lower-constraints.txt files?
I should rephrase. Yes, I'm looking into requirements.txt to translate this into the dependencies in debian/control. The exact workflow, is to compare what's in requirements.txt and what's in the current Debian Stable. If the version is satisfied in Debian Stable, I just don't express any lower bound. If the dependency in Debian Stable isn't high enough, I do write whatever upstream wrote as minimum version in debian/control, meaning that it will need a backported version to Debian Stable to run, or the version in Debian Testing/Unstable. I do expect it to be correct in requirements.txt, and as we always say in the OpenStack world "if it's not tested it's broken"... Which is what bothers me here.
Noting that lower bounds testing isn't feasible and the jobs we were running weren't actually correctly testing minimum versions of everything, these have always been a "best effort" assertion anyway.
Correct, though $topic for this thread is "let's throw away the baby with the bath water"^W^W^W^W "Let's stop testing from all projects". :) If $topic was "let's relax testing on l-c", or "can we find a solution" you'd have my full acceptance, as I can only agree that there's only so much one can do in a day of work, and that our head count is shrinking. Though at the same time, I have a hard time understanding a general call for removing useful tests. At the end, I'm not the person that will be maintaining these tests. That's not my role, and I simply wouldn't be able to do that upstream work on the 500+ packages that I maintain (nearly) alone. Though it's my duty to warn the community about the consequences it may have downstream.
I gather you run Tempest tests against your OpenStack packages on Debian already
I'm trying to find the time to do it, but until I have a full CI up and running (which isn't fully the case yet for my installer), it's still a manual, and painful process. :/ I'm close to having such a CI up and running, though with my current setup, it demands a lot of resources (ie: a machine with 256GB of RAM). Contributions would be very much appreciated.
so if a dependency there is too low you'll find out and can let the project maintainers know that their minimum version for that in requirements.txt isn't correct.
It happened numerous times that I did such bug report. Which proves 2 things: - that it's not tested (enough) - that testing would be useful
Hopefully that doesn't come up very often
It used to be that it was about 5 or 6 times per release. People working on each project for long enough can probably remember me asking about failed unit tests, and being told to upgrade this or that. This type of trouble may mean spending 2 or 3 days not understanding what's happening, until someone on IRC, knowing the project well enough, just finds out in 5 minutes. Since the tested l-c, I can't remember finding out such a problem that wasn't my fault, so it was a huge improvement. One also has to keep in mind that, if on a single release, I can find 5 or 6 times a wrong lower-bound in a requirements.txt, this probably means 10 times more wrong lower bounds really being there. I don't see most problems, because I don't test lower-bound myself, and try to package as much as possible what's in u-c. So I just happen to bump into something I forgot to upgrade *AND* upstream has a wrong lower-bound.
but for things we can't realistically test, getting notified by downstream distributors and users is the best feedback mechanism we can hope for.
Something I don't understand: why can't we use an older version of pip, if the problem is the newer pip resolver? Or can't the current pip be patched to fix things? It's not as if there was no prior art... Maybe I'm missing the big picture? On 1/19/21 7:16 PM, Ghanshyam Mann wrote:
Yeah, in requirments.txt we always have a lower bound of deps and we do not update it or sync it with u-c. Yes, we will not be testing those as such but as Jeremy mentioned if there is some wrong lower bound then we can fix it quickly.
Usually, on every new feature or interface deps, we do bump that lower bound in requirements.txt. We usually check if anything new we are using that is being updated in this file or not
From a downstream distribution package maintainer, having an upstream to do that work, is just super nice and rare. Though the manual process that you describe above is far from trivial, and very error-prone, unfortunately. And this isn't specific to OpenStack of course.
Cheers, Thomas Goirand (zigo)