| *** rlandy is now known as rlandy|out | 01:20 | |
| *** pojadhav- is now known as pojadhav | 08:26 | |
| *** pojadhav is now known as pojadhav|holiday | 08:27 | |
| *** arx|2023 is now known as arxcruz | 08:36 | |
| *** gthiemonge_ is now known as gthiemonge | 12:32 | |
| gthiemonge | Hi Folks, we have new failures in the Octavia jobs: https://zuul.opendev.org/t/openstack/build/2f1d35ae4565450d95025450d851cfd1 | 14:35 |
|---|---|---|
| gthiemonge | "tox.tox_env.python.api.NoInterpreter: could not find python interpreter matching any of the specs python3.8" | 14:35 |
| gthiemonge | we don't get it.. does it ring a bell? | 14:36 |
| frickler | Fix --skip-missing-interpreters behaviour - by @q0w. (#2649) | 14:41 |
| frickler | tox 4.1.2 vs. 4.0.19 | 14:41 |
| fungi | oh boy | 14:42 |
| frickler | now the question is why tox thinks it needs python3.8 | 14:43 |
| fungi | elsewhere we ended up removing all the basepython and ignore_basepython_conflict settings for tox v4, they were (afaik) only useful during the py3k transition when the default python interpreter on the test platforms was still 2.7 and we wanted to run with 3.x | 14:49 |
| frickler | somehow tox seems to think it needs to check for basepython to be available for all envs before it starts doing anything, dropping those resolves the issue indeed | 14:54 |
| gthiemonge | fungi: frickler: thanks! we're trying to fix it | 15:02 |
| *** dviroel is now known as dviroel|lunch | 15:17 | |
| tweining | with little success so far though ;) | 15:19 |
| Clark[m] | I've mentioned it elsewhere but ai think projects should consider nox which has a much simpler set of tools that appear to behave more reliably | 16:18 |
| fungi | that's going to be a bit of effort for openstack since their standard test interface is basically tox-specific, so there are release tooling and job template tendrils into all official deliverables expecting working tox configs. some of those projects could probably pioneer a piecemeal parallel migration starting with the non-mandatory jobs though while working to get buy-in from the tc, | 16:32 |
| fungi | release team, et cetera | 16:32 |
| Clark[m] | Ya it will require effort, but maybe that is a good thing if tox updated which break you multiple times a week stop affecting you | 16:33 |
| Clark[m] | Can pretty easily modify things to handle nox or tox. Zuul-jobs is already doing a bit of this for siblings and artifact retrieval | 16:34 |
| fungi | agreed, unfortunately i expect a migration from tox to nox will be a year or more in the making for openstack, which means projects will still be scrambling to keep tox working too | 16:34 |
| fungi | and if tox development settles down before then, the migration effort could lose steam due to lack of interest and end up indefinitely incomplete | 16:35 |
| fungi | so that needs to be planned around as well | 16:35 |
| Clark[m] | The python version issue is handled quite well by nox. You basically pass a flag on the command line saying use this python version independent of the target (session) name | 16:35 |
| fungi | i would probably start by getting support into places like the release jobs that propose tox.ini patches to projects updating their constraints links and such, since the individual projects are going to lag in approving a lot of migration changes anyway even if someone writes those for them (some still haven't gotten around to merging the fixes for project named queues in their zuul configs, | 16:38 |
| fungi | for example, so have no running jobs at all) | 16:38 |
| fungi | basically figure out what scripts and jobs openstack has that attempt to perform tox configuration management across projects and make them nox-aware | 16:40 |
| fungi | and once that's done, convince the tc to allow individual projects who have the necessary time and interest to start moving their jobs from tox to nox | 16:41 |
| *** dviroel|lunch is now known as dviroel | 16:43 | |
| fungi | there's also going to be a ton of sunk-cost-fallacy arguing, because a lot of devs are going to be more interested in whatever is the fastest path to being able to go back to not caring about tox or nox or job configuration or anything besides their actual software | 16:44 |
| Clark[m] | Ya and ultimately I'm fine with openstack deciding not to do it. Having spent two weeks debugging tox and a week or so converting zuul to nox I'm very happy with nox's simplicity and use of standard tooling paths | 16:45 |
| Clark[m] | Upstream tox is hostile to feedback and doesn't seem to care about users if behavior must be changed for speed | 16:45 |
| fungi | yes, in a green field project or where the benefits for that investment are a clear win, i think nox is a superior choice these days | 16:46 |
| fungi | projects with insanely complex and massive tox configs on the other hand are probably going to just end up sticking with tox even if nox would technically be beneficial for them in the long run | 16:47 |
| Clark[m] | The other behavior I ran into recently is that tox will update to latest tox if you use tox requires | 16:48 |
| Clark[m] | So you're forced to handle all of tox's latest behaviors even if you pin tox | 16:48 |
| fungi | yes, i didn't realize that was the case, but apparently it has been for the past year or two | 16:48 |
| Clark[m] | For me as a user that is the nail in the coffin... | 16:49 |
| opendevreview | Merged zuul/zuul-jobs master: Update fetch-subunit-output to look for nox envs https://review.opendev.org/c/zuul/zuul-jobs/+/868912 | 18:36 |
| *** dviroel is now known as dviroel|out | 21:18 | |
Generated by irclog2html.py 2.17.3 by Marius Gedminas - find it at https://mg.pov.lt/irclog2html/!