Open Stack

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)