fuel-web has wrong test-requirements in nailgun/test-requirements.txt

[Thomas Goirand]

The nailgun/test-requirements.txt is full of == values, when it really should have >= instead. Otherwise these build-dependencies aren't satisfiable in distributions (like Debian Sid), which constantly evolve. More over, some of these pinnings are completely outdated, like for example an antique version of nose (ie: the one in Trusty).

More generally, fuel-web needs to follow the global-requirements.

[Ilya Kutukov (ikutukov)]

I think pinned and unpinned versions have their own pros and cons.

Of course, versions should be updated, but this is very bad idea to update them automatically (read accidentally) including major version libraries, because library developers know nothing about our development cycle and when we are ready to face the problems of version migration.

I don't think that blind versions update is correct policy of course if we don't like sudden panics without exact information where destructive changes is, in our or 3-rd party code.

Just as an example when latest tox release was completely broken and we have a week with not passing CI for Fuel CLI: https://bugs.launchpad.net/fuel/+bug/1517427

[Thomas Goirand (thomas-goirand)]

Ilya, this has been discussed for a *VERY* long time in the openstack-dev list. What we want here *is* to face the breakage, so that engineer who work on the product do notice them. Otherwise, the problems affected by newer versions never get even noticed.

So what we want is to *not* put an upper bound *unless* we are absolutely certain there's an issue. In such a case, a temporary upper bound can be set, and then someone should be assign to try to fix the issue (fixing the issue means make the actual software work with the newer version of the library, *not* setting an upper bound).

This also, as you just mentioned, helps finding out upstream breakages early. In this case with tox, probably the broken version should have just been blacklisted.

All what I'm saying above is what's currently done within the OpenStack gate. We should do the same, and anyway, align with the global-requirements.txt.