Open Stack

On 07/18/2018 06:42 AM, Ian Wienand wrote:
> While I'm reserved about the
> idea of full platform functional tests, essentially having a
> wide-variety of up-to-date tox environments using some of the methods
> discussed there is, I think, a very practical way to be cow-catching
> some of the bigger issues with Python version updates.  If we are to
> expend resources, my 2c worth is that pushing in that direction gives
> the best return on effort.
> 
> -i

Hi Ian,

Thanks a lot for your reply, that's very useful. I very much agree that
testing the latest Qemu / libvirt could be a problem if it fails too
often, and same with other components, however, these needs to be
addressed anyway at some point. If we can't do it this way, then we have
to define a mechanism to find out. Maybe a dvsm periodic task unrelated
to a specific project would do?

Anyway, my post was *not* about functional testing, so let's not talk
about this. What I would love to get addressed is catching problems with
newer language updates. Having them early avoids downstream distribution
doing the heavy work, which is not sustainable considering the amount of
people (which is about 1 or 2 guys per distro), and that's what I would
like to be addressed.

For example, "async" becoming a keyword in Python 3.7 is something I
would have very much like to be caught by some kind of upstream CI
running unit tests, rather than Debian and Ubuntu package maintainers
fixing the problems as we get FTBFS (Fails To Build From Source) bugs
filed in the BTS, and when we find out by ourselves that some package
cannot be installed or built. This happened with oslo.messaging,
taskflow, etc. This is just the new Python 3.7 things, though there was
numerous problems with Python 3.6. Currently, it looks like Heat also
has unit test failures in Sid (not sure yet what the issue is).

Waiting for Bionic to be released to start gating unit tests on Python
3.6 is IMO a way too late, as for example Debian Sid was running Python
3.6 about a year before that, and that's what I would like to be fixed.

Using either Fedora or SuSE is fine to me, as long as it gets latest
Python language fast enough (does it go as fast as Debian testing?). If
it's for doing unit testing only (ie: no functional tests using Qemu,
libvirt and other component of this type) looks like a good plan.

Cheers,

Thomas Goirand (zigo)