Monday, 2023-01-02

*** rlandy is now known as rlandy|out01:20
*** pojadhav- is now known as pojadhav08:26
*** pojadhav is now known as pojadhav|holiday08:27
*** arx|2023 is now known as arxcruz08:36
*** gthiemonge_ is now known as gthiemonge12:32
gthiemongeHi Folks, we have new failures in the Octavia jobs:
gthiemonge"tox.tox_env.python.api.NoInterpreter: could not find python interpreter matching any of the specs python3.8"14:35
gthiemongewe don't get it.. does it ring a bell?14:36
fricklerFix --skip-missing-interpreters behaviour - by @q0w. (#2649)14:41
fricklertox 4.1.2 vs. 4.0.1914:41
fungioh boy14:42
fricklernow the question is why tox thinks it needs python3.814:43
fungielsewhere 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.x14:49
fricklersomehow 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 indeed14:54
gthiemongefungi: frickler: thanks! we're trying to fix it15:02
*** dviroel is now known as dviroel|lunch15:17
tweiningwith 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 reliably16:18
fungithat'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
fungirelease team, et cetera16: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 you16: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 retrieval16:34
fungiagreed, 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 too16:34
fungiand if tox development settles down before then, the migration effort could lose steam due to lack of interest and end up indefinitely incomplete16:35
fungiso that needs to be planned around as well16: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) name16:35
fungii 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
fungifor example, so have no running jobs at all)16:38
fungibasically figure out what scripts and jobs openstack has that attempt to perform tox configuration management across projects and make them nox-aware16:40
fungiand 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 nox16:41
*** dviroel|lunch is now known as dviroel16:43
fungithere'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 software16: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 paths16:45
Clark[m]Upstream tox is hostile to feedback and doesn't seem to care about users if behavior must be changed for speed16:45
fungiyes, in a green field project or where the benefits for that investment are a clear win, i think nox is a superior choice these days16:46
fungiprojects 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 run16:47
Clark[m]The other behavior I ran into recently is that tox will update to latest tox if you use tox requires16:48
Clark[m]So you're forced to handle all of tox's latest behaviors even if you pin tox16:48
fungiyes, i didn't realize that was the case, but apparently it has been for the past year or two16:48
Clark[m]For me as a user that is the nail in the coffin...16:49
opendevreviewMerged zuul/zuul-jobs master: Update fetch-subunit-output to look for nox envs
*** dviroel is now known as dviroel|out21:18

Generated by 2.17.3 by Marius Gedminas - find it at!