Wednesday, 2022-12-07

ianwi've noted it in the etherpad and added a checklist point at the end.  i'll turn it back *on* for https://173.231.255.71/ so we don't have confusion00:00
Clark[m]That seems reasonable00:09
opendevreviewMerged opendev/system-config master: install-ansible: overhaul install ansible requirements  https://review.opendev.org/c/opendev/system-config/+/86654201:34
ianwhttps://173.231.255.173 has been cycled from 3.5 -> 3.6 -> 3.5 with downgrade process.  01:53
ianwoutput is https://paste.opendev.org/show/b6QBme2ellt5nQ5FYtNT/01:53
ianwthe illegal reflective access looks exactly like https://bugs.chromium.org/p/gerrit/issues/detail?id=12639, but that was marked as fixed01:54
ianwi'll investigate01:54
ianwnote it also happens on 3.5.4, so not a regression as such01:55
Clark[m]I think there is a known thing with guice and java 1102:19
ianwyeah everything sort of says it's fixed in 5.0.1, which should be included ...02:28
ianwtools/nongoogle.bzl:    GUICE_VERS = "5.0.1"02:28
ianwI've filed https://bugs.chromium.org/p/gerrit/issues/detail?id=16506 ... it looks the same as the original bug but it's not fixed, and the other is closed02:54
ianwi've sent the notification but it's hit moderation03:20
Clark[m]I can send it through tomorrow morning but my secrets content isn't currently accessible03:24
opendevreviewFrikin Evgenii proposed openstack/diskimage-builder master: Add variable for check installing python3 in yum element  https://review.opendev.org/c/openstack/diskimage-builder/+/85657703:25
ianwClark[m]: no rush, just ticking things off the checklist :)03:25
ianwansible-playbook [core 2.14.1] ... that lg on bridge.  hourly run is going and seems fine so far03:26
ianwhttps://gitlab.com/mailman/hyperkitty/-/merge_requests/485 is for the no-margin on hyperkitty i mentioned yesterday03:56
*** yadnesh|away is now known as yadnesh04:43
opendevreviewMerged opendev/system-config master: install-ansible: update venv once a day  https://review.opendev.org/c/opendev/system-config/+/86663304:59
*** ysandeep is now known as ysandeep|brb05:07
*** ysandeep__ is now known as ysandeep05:51
*** marios is now known as marios|ruck06:19
*** yadnesh is now known as yadnesh|afk07:46
*** jpena|off is now known as jpena08:41
*** yadnesh|afk is now known as yadnesh08:49
opendevreviewJiri Podivin proposed openstack/project-config master: Releasing tripleo-ansible as PyPi deliverable  https://review.opendev.org/c/openstack/project-config/+/86683909:48
*** dviroel|biab is now known as dviroel11:14
*** rlandy|out is now known as rlandy|rover11:14
*** yadnesh is now known as yadnesh|afk11:50
*** yadnesh|afk is now known as yadnesh12:34
*** frenzy_friday is now known as frenzy_friday|food13:09
*** pojadhav is now known as pojadhav|afk13:48
*** ysandeep is now known as ysandeep|out13:59
*** dasm|off is now known as dasm14:43
*** pojadhav|afk is now known as pojadhav14:46
opendevreviewThierry Carrez proposed opendev/irc-meetings master: Move Large Scale SIG meeting on even weeks in 2023  https://review.opendev.org/c/opendev/irc-meetings/+/86687315:24
fungittx: frickler has a comment/question on ^15:29
*** frenzy_friday|food is now known as frenzy_friday15:34
opendevreviewThierry Carrez proposed opendev/irc-meetings master: Move Large Scale SIG meeting on even weeks in 2023  https://review.opendev.org/c/opendev/irc-meetings/+/86687315:38
ttxgood point, fixed !15:39
opendevreviewMerged opendev/irc-meetings master: Move Large Scale SIG meeting on even weeks in 2023  https://review.opendev.org/c/opendev/irc-meetings/+/86687315:46
clarkbfungi: looks like you got the gerrit upgrade announcement? I was just logging in to check that15:56
fungiyep15:56
clarkbthanks! (this new ui is much nicer)15:57
fungii wanted to double-check that the moderation functionality was working as expected15:57
fungii'll let you get the next one15:57
clarkbno worries. I was just making sure i got to it15:57
clarkbmy todo list is starting to build a collection of writing activities for when things slow down a bit more. Today though I need to find breakfast and then look at nodepool test failures and lack of openstack api statsd info16:00
*** dviroel is now known as dviroel|lunch16:15
clarkbfungi: are we restoring list server dns record ttls todayish? I'm not in a rush just don't want to forget16:20
fungiyeah, and merging the config removal for the old server too i guess16:22
fungilemme un-wip16:22
clarkbfungi: oh and we should restart things for the site_owner update and double check /etc/mailman.cfg is properly updated in the container?16:22
fungiyes16:23
fungiso the remaining non-dnm changes for topic:mailman3 should be safe to merge now16:23
*** marios|ruck is now known as marios|out16:40
opendevreviewAde Lee proposed zuul/zuul-jobs master: Add ubuntu to enable-fips role  https://review.opendev.org/c/zuul/zuul-jobs/+/86688117:11
*** yadnesh is now known as yadnesh|away17:14
*** dviroel|lunch is now known as dviroel17:16
*** jpena is now known as jpena|off17:31
clarkbfungi: https://zuul.opendev.org/t/zuul/build/47d0916427b14372bfedbbd7a4e91a61/log/job-output.txt#869-933 at first I thought this might be something we're doing wrong with apt-key but digging more it seems there are a ton of bugs around ansible just getting this wrong :/ but thought I'd share it because I think a workaround is to just drop the Release.key file into18:23
clarkb/etc/apt/something/something.gpg instead? will that work on focal and newer?18:23
clarkbapparently it does a check after adding the key to see if it is present and if they don't process that correct we get this error which I expect is a bug in ansible and not with the key itself18:28
clarkboh I think apt_key module wants us to pass in an id to cross check against and we are not doing that18:31
opendevreviewClark Boylan proposed zuul/zuul-jobs master: Specify crio repo key ids for apt_key  https://review.opendev.org/c/zuul/zuul-jobs/+/86692018:35
fungiclarkb: yes, well i think raw .gpg files will work there for even older releases but .asc needs at least focal?18:43
clarkbah18:45
clarkbI'm shifting gears now beacuse I think tox siblings is completely broken possily due to a tox release18:45
fungiooh, ouch18:47
fungi4.0.0... looking through the changelog now18:48
fricklerah, was just about to mention it. https://tox.wiki/en/latest/faq.html#breaking-changes-in-tox-418:50
fungiyup18:51
fungi"breaking" is no understatement18:51
fricklerI did some sporadic testing earlier and got one small issue fixed from rc1, but likely there's more18:51
fungimentioned in #openstack-infra but lots of projects are going to need to replace whitelist_externals18:51
fungiit's been deprecated for a while but removed in 4.0.018:52
clarkbI wonder if it could possibly be the color output confusing things18:54
clarkbI think a change to set the no color flag will be self testing in zuul-jobs so I'll give that a go18:54
fungiooh maybe18:57
clarkbproblem is I dunno if old tox will accept --colored no18:58
clarkbI guess I can set NO_COLORS=0 in the env instead and it should ignore that18:58
fungiyeah, that ought to be safe19:02
clarkbNO_COLORS=0 isn't working for me on the command line19:05
fungiouch, also all existing tox plugins need a rewrite?19:05
clarkbneither is NO_COLORS=119:05
clarkbTERM=dumb does work19:05
clarkbbut that is a bit more side effecting since other things may look for the TERM value19:06
clarkbarg19:06
fungiyeah, just reached that part of the faq19:06
clarkbhttps://github.com/tox-dev/tox/search?q=NO_COLORS19:07
clarkbso they aren't doing anything explicitly with that flag in the code? this is bonghits19:07
clarkbhahahahahahahahaha19:07
fungithat's what i was about to verify too19:07
clarkbNO_COLOR=1 works19:07
clarkbI'm going to need a drink and it isn't even noon yet19:07
fungiokay, so faq double-typo19:07
* clarkb edits the change that is basically done to fix it19:08
fungiclearly you're not the only one drinking on the job if this is any indication ;)19:08
fungii'm willing to bet the implementation started out expecting COLORS=0 and then got changed to NO_COLOR=1 somewhere along the way, and whoever was writing up the faq got them swizzled around19:09
fungii replied to the discord thread where it was announced, pointing that out19:11
fungier, discuss19:12
opendevreviewClark Boylan proposed zuul/zuul-jobs master: Set tox NO_COLOR=1 flag  https://review.opendev.org/c/zuul/zuul-jobs/+/86692619:12
clarkbI believe ^ will be self testing19:12
clarkbnote I'm not sure if this will break tox siblings for target envs that don't show up in --showconfig19:13
clarkbI'm not sure what we are doing with --showconfig and how it might be affected by the changed output yet. Its weird because running tox -e docs seems to work and do what we have set but then yo udon't actually get the showconfig output you expect19:14
clarkbI think if 866926 isn't a clear win the next thing to try is pinning tox < 4.0 for now in zuul-jobs then have a change to remove the cap be self testing of things19:15
clarkbhonestly that might be better anyway?19:15
clarkbI'll work on that change now too19:15
clarkbNO_COLOR didn't help and its the same error. Pin change should be up momentarily19:17
opendevreviewClark Boylan proposed zuul/zuul-jobs master: Pin tox to <4 in ensure-tox installation  https://review.opendev.org/c/zuul/zuul-jobs/+/86692819:19
fungii've sent something to the openstack-discuss ml on behalf of the tact sig, but other project liaisons may want to follow suit19:20
opendevreviewClark Boylan proposed zuul/zuul-jobs master: Pin tox to <4 in ensure-tox installation  https://review.opendev.org/c/zuul/zuul-jobs/+/86692819:32
clarkbfungi: do you have a link to the discuss discussion around tox 4? Might be good so that we can follow problems others have19:33
fungiclarkb: https://discuss.python.org/t/tool-tox-4-on-the-horizon/6537/2619:34
clarkbthank you19:34
opendevreviewJames E. Blair proposed zuul/zuul-jobs master: Make zuul-tox-docs voting again  https://review.opendev.org/c/zuul/zuul-jobs/+/86692919:36
clarkbfungi: '# !!! unused: whitelist_externals' gets emitted to --showconfig output when you use the invalid flags19:43
clarkbbasically tox is ignoring it and not breaking on it. Which should be fine for that one in particular since all it does is warn if you escape the venv19:43
clarkbusedevelop is also ignored and I expect that to be more problematic19:43
clarkbin zuul/zuul-jobs --showconfig only emits envs for [tox] and [tox:linters}19:44
clarkboh beacuse it doesn't emit the whole thing only what is in your envlist? so maybe this is ok19:44
clarkbya ok19:45
rlandy|roverfungi++ clarkb++ - thanks for quick response on the tox 4.0.0 bloodbath19:47
frickleralso the quoting seems to have gotten messed up, try tox -e linters in zuul-jobs after fixing the allowlist_externals19:49
opendevreviewMerged zuul/zuul-jobs master: Pin tox to <4 in ensure-tox installation  https://review.opendev.org/c/zuul/zuul-jobs/+/86692819:51
clarkbdoing a naive `tox -edocs --showconfig > newshownconfig` and then loading it into https://opendev.org/zuul/zuul-jobs/src/branch/master/roles/tox/library/tox_install_sibling_packages.py#L312-L330 produces no errors under my local python3.10 install19:56
fungihave you diffed 3.x output against it?19:58
fungimaybe that would yield clues19:58
clarkbya its very different19:59
clarkbI'm not sure that will behelpful since tox seems tohave changed it so dramatically19:59
fungii guess it's a question of whether the bits tox_install_sibling_packages.py tries to parse out of it are different20:00
fungii half wonder if it's changed from old ini format to toml20:01
clarkbI don't think so as it seems to be valid ini when I do the config parsing locally20:02
clarkbbasically I'm using tox 4 -e docs --showconfig > file. Then loading that file into the block of code I linked to above and it works without complaint20:02
fungivalid as in successfully parsed by configparser, but with the same actual data?20:02
clarkbfungi: yes successfully parses without error as far as I can tell20:03
opendevreviewMerged zuul/zuul-jobs master: Make zuul-tox-docs voting again  https://review.opendev.org/c/zuul/zuul-jobs/+/86692920:03
clarkbnow whether or not it is identical input data is harder to say. There are probably some hacks we can do20:03
clarkbya let me push a DNM change up to try and capture that info20:03
opendevreviewClark Boylan proposed zuul/zuul-jobs master: DNM Cat the tox --showconfig output under tox v4  https://review.opendev.org/c/zuul/zuul-jobs/+/86693520:06
clarkbthat should cat the file that is being read so we can see what exactly is being processed20:06
fricklerthat's the quoting thing, can be workarounded by s/#/\#/ https://github.com/tox-dev/tox/issues/261720:08
* frickler has enough for today20:09
clarkbfrickler: I'm not sure I understand the quoting thing?20:09
clarkbI haven't been abel to reproduce parsing errors locally20:09
fricklerthe # is parsed as comment character even when it is within the bash command, so tox tries to execute only the half of the command up to the #20:10
clarkbI see and maybe that is breaking the output of --showconfig?20:10
clarkbI guess we'll see data soon enough20:11
clarkband ya enjoy your evening I think we've sufficiently worked around this that we can take our time to solve the underlying issues with v420:11
fricklerI think those may be two independent issues20:12
clarkbgot it20:12
*** dviroel is now known as dviroel|brb20:14
clarkbheh I can't yaml. new ps for the debugging change momentarily20:17
opendevreviewClark Boylan proposed zuul/zuul-jobs master: DNM Cat the tox --showconfig output under tox v4  https://review.opendev.org/c/zuul/zuul-jobs/+/86693520:18
clarkbfungi: I think you can probably followup to your openstack-discuss list email saying things should be pinned to latest v3 and working?20:19
fungiyeah, i wanted to be sure we didn't spot anything else problematic but seems stabilized now20:22
clarkbtox v4 is prefixing lines with stuff like ROOT: 238 I  but it doesn't do that for me locally20:23
clarkbyou end up with multiple lines with ROOT: at th estart which breaks the ini20:23
clarkb Ithink this is a tox bug since showconfig should emit valid config, but we should probably handle it anyway, file a bug and hope they fix it20:24
clarkbbut if they don't we've handled it and can take it from there20:24
clarkbI'm going to find lunch now, but thats the next thing to figure out, why I don't get that output locally and how to turn it off in zuul like it seems to eb turned off here20:24
fricklerthe main diff I see is that tox4 has multiline output for e.g. "pass_env", for tox3 that is shown as a list in a single line20:27
fricklerand now I'm really gone ;)20:28
opendevreviewClark Boylan proposed zuul/zuul-jobs master: DNM Cat the tox --showconfig output under tox v4  https://review.opendev.org/c/zuul/zuul-jobs/+/86693520:41
clarkbok its due to add -v or -vv (we add -vv by default). ^ hasbeen updated to remove the extra args from the show config command which I think is what we want to control the ini content more directly20:41
clarkbI still think that is a bug in tox though. They should prefix the -v output with ini comments20:42
clarkbI didn't actually find lunch yet so I should actually do that now I guess20:42
fungiyeah, i think in tox v3 it still produced valid ini content20:44
fungiand used comments20:44
fungii recall that being a bug in older tox which they fixed, but i guess they regressed it in v420:45
clarkbthat updated patch fixed the configparser error and now we've got real errors due to the delta between versions I think20:46
fungi(verbose output originally broke the ability to parse it)20:46
clarkbothers should feel free to push updates to that chagne I won't mind and I really need to sort out food now20:46
fungii too need to go for food, my dinner order should be ready for pickup shortly, but i'll bbiab20:46
clarkbenvdir is now env_dir so we need to check for both I guess20:47
clarkband map any of the other things we look for that might have moved :(20:47
*** dviroel|brb is now known as dviroel|afk20:47
ianwsorry, running a little late today ... i saw some toots about tox 4 being a "complete rewrite" 21:11
ianwi'm guessing that pretty much means we have complete failures21:12
clarkbya it appears to be quite different21:12
clarkbtox v3 --showconfig would show you the args you are executing under so you could determine i -e was set or not. Tox v4 does not do this and tox siblings uses this info to determine what environments to do siblings installs in21:12
clarkbI'm not seeing an obvious method for getting that info we culd use instead21:13
clarkboh it does print the default envs as testenvs though so I think that is what we have to is only look at testenvs21:13
JayFHow do new groups get created in Gerrit? 21:18
JayFIf it's in git; I can't find it. If it's in gerrit; I can't find it :D 21:18
clarkbJayF: you put them in the gerrit acl file that you want to use them with and it gets created21:18
clarkbJayF: via openstack/project-config/gerrit/acls21:18
JayFack; so just reference the group and it gets created21:18
JayFand then I assume I need to nudge someone with admin access to get membership set?21:19
fungiokay, i'm back and typing with my non-chopstick hand for now21:19
fungiJayF: correct. refer to a nonexistent group name in an acl and automation will create the missing group as empty when that change merges, the one of the gerrit admins can add an initial user for you (if it's an openstack repo, then generally it will be the ptl or tact sig liaison)21:22
opendevreviewClark Boylan proposed zuul/zuul-jobs master: DNM Cat the tox --showconfig output under tox v4  https://review.opendev.org/c/zuul/zuul-jobs/+/86693521:22
JayFokay; I'm going to start work on https://lists.openstack.org/pipermail/openstack-discuss/2022-December/031372.html21:22
clarkblooks like env_dir is canonical now but tox will still honor envdir in your tox.ini which is good because things like tempest use envdir21:25
clarkbI suspect that 866935 is close to working for zuul-jobs under tox v421:26
clarkbthe quoting issue that frickler found seems like an important one so maybe we should plan for switching back to tox v4 by default once they have a release that fixes that?21:27
fungiprobably, and maybe let projects know to test it with depends-on to spot anything else21:28
clarkbya that sounds like a good plan. Once I get CI results back assuming it runs cleanly I'll update the change to be mergeable21:28
clarkbthen I can WIP it and we can make a plan?21:28
opendevreviewJay Faulkner proposed openstack/project-config master: ironic-release group for releasing+maint of bugfix  https://review.opendev.org/c/openstack/project-config/+/86693721:29
fungiwfm21:30
clarkblooks like there may be a few more failures I need to address21:31
clarkboh also we should file a bug upstream about --showconfig emitting debug lines without comments21:31
clarkbit looks like old tox doesn't emit them at all even when called with -vv21:32
fungii think it used to, but not sure i can find the point at which they fixed that without a lot of fiddling21:32
clarkblet me check if its on a different fd too21:33
fungii know there was one point at which combining verbose and showconfig resulted in extra lines you needed to strip off before you could parse the output21:33
clarkbits not its all stdout21:33
clarkbfungi: yup there are a couple of prefix lines but they ren't part of the problem here21:33
clarkbas they aren't interleaved21:33
clarkbso you just ignore the first couple of lines basically (not great but much better than interleaved content)21:34
clarkbwait when did whitelist/allowlist become and error instaed of a warning21:34
clarkbugh21:34
clarkbthats going to be the biggest issue I bet21:34
corvusif tox is breaking backwards compat now, then we probably need a version specifier in the ensure-tox role21:36
corvus(like an ensure_tox_version argument)21:37
clarkbcorvus: ack I can incorporate that into what I'm writing here21:37
clarkbcorvus: do we think default to latest and let people override? thats probably best for preventing things from becoming ancient21:37
fungicorvus: elodilles has a change proposed for that21:38
fungiit's been up for a while and may need some comments addressed, but may be a good place to continue from21:38
clarkbfungi: I'll try to find it and rebase on that I guess21:38
fungiit showed up in conflicts for the tox<4 pin change is the only reason i remembered it21:38
corvusi think the resulting patch will have zero lines in common with 76644121:38
fungiahh21:39
fungibut will obsolete it at least21:40
corvusas for defaults... perhaps it should default to latest... but given the catastrophic breakage, maybe we should start by defaulting it to 3 and then moving to latest in 2 weeks?21:41
clarkbthere is a not small part of me that wonders if it wouldn't just be easier to move to nox. But I know that isn't the case21:41
clarkbcorvus: ++21:41
clarkbcorvus:  Ithink we don't want latest until tox fix the string quoting issue frickler found. That is a critical issue to me21:41
corvuseven better reason to intentionally pin for now21:42
clarkbthey no longer prefix tox logs with the env name in the file name so we have to do that when fetching logs...21:47
clarkbugh21:49
fungiat what point do we decide that tox4 is so different than tox<4 that it's a separate tool which needs its own jobs/roles? i guess we're not quite to that point yet...21:51
corvusi think some of us may be close21:53
* corvus is reading nox manual21:54
corvushttps://github.com/wntrblm/nox/pull/677 is amusing ("Constrain tox to <4.0.0 and minor fixes") -- it's for their tox_to_nox tool21:56
opendevreviewClark Boylan proposed zuul/zuul-jobs master: Update zuul-jobs to handle tox3 and tox4  https://review.opendev.org/c/zuul/zuul-jobs/+/86693522:04
opendevreviewClark Boylan proposed zuul/zuul-jobs master: Move tox logs into env specific dirs  https://review.opendev.org/c/zuul/zuul-jobs/+/86693922:04
clarkb866939 move tox logs into venv specific dirs under tox v3 as that should be fine to do before v4. Then the followup change does a number of things to try and make tox v4 work under zuul-jobs dogfood testing22:05
corvusclarkb: q's on 93522:09
opendevreviewJay Faulkner proposed openstack/project-config master: ironic-release group for releasing+maint of bugfix  https://review.opendev.org/c/openstack/project-config/+/86693722:09
*** dasm is now known as dasm|off22:11
corvusclarkb: oh and of course we'll need docs in the readme22:11
corvusfor the new var22:11
corvusand remove the zuul-tox-docs comment22:12
clarkbcorvus: ++ your comments are good and need fixing. I'll hold off on pushing an update until I can see more test results just to be sure nothing extra breaks22:12
clarkbcorvus: zuul-tox-docs comment?22:13
clarkbcorvus: looks like the linters jobs are failing on the string problem frickler found. I'm not going to try and fix that now intead I'll leave a comment pointing to the upstream issue and the resulting -1s will prevent us from landing this change too soon22:17
clarkboh nevermind tox says you have to manually escape everything now which is wat22:18
clarkbthats just amazing22:18
corvusclarkb: in zuul-tests.d/project.yaml you have zuul-tox-docs commented out22:19
clarkbcorvus: oh right thanks22:19
opendevreviewClark Boylan proposed zuul/zuul-jobs master: Update zuul-jobs to handle tox3 and tox4  https://review.opendev.org/c/zuul/zuul-jobs/+/86693522:21
corvusclarkb: update looks good -- but did we want to default that to '<4' now and then send an announcement that we're going to change it to ''?22:22
corvusor do we think that the issues of allowlist and escaping are small enough that we should go ahead and default it to '' and just tell people about the new option?22:23
clarkbcorvus: I didn't do that because the log file checks would be wrong, but I think everything else is forward and backward compatible. I guess I can stub out what the >=4 version would look like in that test and we can swap them around when we update the dfeault?22:23
clarkbthe escaped \# are something I'm not sure if they will be backward compatible either. I think allowlist is fine22:24
corvusi kinda like that approach, i think it's friendliest22:24
clarkbcorvus: ok let me see preliminary results from this ps and then I'll update to try that22:24
corvus(basically, any zuul-job user will need to make updates for allowlist + escaping before they upgrade their usage of this role to v4)22:24
clarkbyes22:26
clarkbwell the scaping might only be a problem for ini comment start chars22:26
corvus(and i like the idea of the zuul project not being responsible for tox changes, but this is a super old and widely used role that's making trouble for everyone so providing a good on-ramp as a one-time thing seems nice)22:26
clarkbso if you don't have ; or # you'd be ok? but ya basically those things need addressing22:26
corvusi'll draft a message22:26
clarkbcorvus: in the readme for that role should I say this is likely tochange to '' in the future to default to latest?22:27
clarkbor do you not want to go that far yet?22:27
corvusi think it's fine (but not required) to mention that22:27
*** rlandy|rover is now known as rlandy|out22:29
clarkblinters: 50070 E failed with /home/zuul/src/opendev.org/zuul/zuul-jobs/tools/check_jobs_documented.py (resolves to /home/zuul/src/opendev.org/zuul/zuul-jobs/tools/check_jobs_documented.py) is not allowed, use allowlist_externals to allow it [tox/session/cmd/run/single.py:54]22:30
opendevreviewClark Boylan proposed zuul/zuul-jobs master: Update zuul-jobs to handle tox3 and tox4  https://review.opendev.org/c/zuul/zuul-jobs/+/86693522:35
opendevreviewClark Boylan proposed zuul/zuul-jobs master: Flip ensure-tox to tox v4 by default  https://review.opendev.org/c/zuul/zuul-jobs/+/86694322:35
clarkbcorvus: something like that maybe?22:35
corvusclarkb: looks great22:38
corvusclarkb: fungi how's this? https://etherpad.opendev.org/p/6wky6mkVu4uo2c3vaLpJ22:39
fungicorvus: lgtm!22:41
fungithanks22:42
clarkbcorvus: the email looks good. My only concern is that with holidays approaching many people may ignore this until next year? I'm waffling on whether or not december 21 is too early22:42
clarkbbut otherwise looks good to me. I guess if openstack really wants to they can set that value which is the outlet so the 21st is fine?22:42
corvusyeah, timing isn't great.  i think it would be fine to defer that until jan 3 or 10 if you like that better22:43
JayFcorvus: one question I'd have as a PTL reading that: how can I get tox 4 in my project for testing in CI and/or to opt-in once we're working22:44
clarkbJayF: one my change lands you can set ensure_tox_version: '' as a job var22:45
clarkbalternatively do that now and depends on22:45
JayFclarkb: that's what I sorta gleaned from the email; but it might be useful to make that more explicit22:45
clarkbadding that to the email would be good22:45
clarkbya22:45
JayFnone of this stuff is hard; but it's all unfamiliar22:45
opendevreviewMerged opendev/system-config master: create-venv: make upgrade venv once per day  https://review.opendev.org/c/opendev/system-config/+/86664422:47
opendevreviewMerged opendev/system-config master: pip: use latest instead of upgrade  https://review.opendev.org/c/opendev/system-config/+/86664522:48
corvusclarkb: https://zuul.opendev.org/t/zuul/build/452d9393f0ce41429f114941344e83d422:54
corvusoO22:54
corvusfungi: ^ you have a history with that22:59
clarkbI think this may be a quoting issue too23:00
clarkbhttps://github.com/tox-dev/tox/issues/2622 for --showconfig problems23:01
clarkbcorvus: is it just tox_extra_args set to that path? that is weird23:03
corvusclarkb: JayF i'm at a loss on how to improve the last sentence of the email to address JayF's point while keeping in mind the audience of the list the subscribers to zuul-announce (ie, not just openstack).  if you have any suggestions, please feel free to update the etherpad!23:03
fungilooking23:03
JayFthat's an improvement for sure; ty23:04
corvusclarkb: i, er, don't understand what's going on here.  i may be getting distracted by "ROOT: tox-bindep disabled itself as it does not support tox4 yet." is that just a red herring?23:05
clarkboh I need to drop the show config output so will need a new ps anyway23:05
clarkbcorvus: no I think that may be part of it since we start with tox v3 when we ensure-tox (I checked that)23:05
clarkbcorvus: so maybe it is upgrading tox as part of that job specially? I'll look at that idea23:05
corvusclarkb: i thought that should be running with 3 though: https://zuul.opendev.org/t/zuul/build/452d9393f0ce41429f114941344e83d4/console#1/0/18/ubuntu-jammy23:06
fungicorvus: i think tox-bindep is something sbarnea made. tox v4 does not support plugins made for tox<4 according to the breaking changes faq23:06
clarkbcorvus: it seems to be runnin tox multiple times though and I'm wondering if it is updating tox in between somehow?23:07
fungihttps://github.com/tox-dev/tox-bindep23:07
corvusfungi: i agree -- and i think (1) it's confusing why it's running at all in an environment that should be tox3 but as clarkb says maybe it's getting upgraded during the test run... but also (2) we may need to change that if we want this test job to run tox423:08
corvusfungi: re #2 -- is there something else we can add to requirements that is compatible with tox4?23:08
fungiit does say `.tox installdeps: tox-bindep, tox >= 3.2`23:08
clarkbthe child changes which flips to tox v4 globally does pass this test23:09
corvusclarkb: that only adds to my confusion!23:09
fungiis the goal to test that we can install a tox plugin? trying to figure out what tox-bindep is used for there and why23:09
clarkboh its because it depends on tox >= 3.223:09
clarkbfungi: where is that installdeps line? in tox-bindep?23:10
clarkbI think we just stop doing anyhting with tox-bindep since its broken23:11
corvusclarkb: i think fungi was referring to https://zuul.opendev.org/t/zuul/build/452d9393f0ce41429f114941344e83d4/log/job-output.txt#186623:11
corvusthe job claims to have installed tox 3.27.1 which seems to match that requirement to me, so i don't know why it would self-upgrade...23:11
clarkbhttps://github.com/tox-dev/tox-bindep/blob/main/setup.cfg#L50 and that comes from here I think23:12
clarkbcorvus: its installing tox-bindep which depends on tox>=3.18 or whatever which pulls in a nested tox 4.0.0 in the end which breaks because tox-bindep isn't a compatible plugin23:12
clarkbI think I have a fix and if it doesn't work we can just delete this test23:12
fungiahh, commit message which introduced it says we're testing the "requires" feature of tox.ini23:12
corvusclarkb: but if it's starting with 3.27.1 why would it decide to upgrade for 3.18?23:13
clarkbbecause this is a tox being installed in a tox env23:13
clarkbtox all the way down23:14
corvusclarkb: ah gotcha23:14
opendevreviewClark Boylan proposed zuul/zuul-jobs master: Update zuul-jobs to handle tox3 and tox4  https://review.opendev.org/c/zuul/zuul-jobs/+/86693523:14
opendevreviewClark Boylan proposed zuul/zuul-jobs master: Flip ensure-tox to tox v4 by default  https://review.opendev.org/c/zuul/zuul-jobs/+/86694323:14
corvusclarkb: any idea why the followup change passes this test?23:14
clarkbcorvus: what is confusing to me is how the v4 flip job passed23:14
clarkbcorvus: ya that I'm confused about.23:14
fungiyeah, looks like tox is being told to install another tox in a venv, so new install completely23:14
clarkbcorvus: oh that test doesn't run on the child change for some reason23:15
corvusclarkb: i was just about to say that23:15
clarkbI skipped and thought it did, but it does not. I'll update the child change file matcher to match ensure-tox role23:15
corvussounds good and that sounds like a plausible explanation23:15
fungihttps://github.com/tox-dev/tox-bindep/issues/2523:15
fungilovely23:16
corvusso i think the remaining question is -- is there something other than tox-bindep we should use to address the original issue for https://review.opendev.org/812004 ?23:16
opendevreviewClark Boylan proposed zuul/zuul-jobs master: Flip ensure-tox to tox v4 by default  https://review.opendev.org/c/zuul/zuul-jobs/+/86694323:16
clarkbcorvus: any small pip installable might work?23:16
corvusrequestsexceptions is small23:17
fungiyeah. seems fine23:18
clarkbI need to read this test job a bit more to undersatnd how it is checking things23:18
clarkbits doing https://opendev.org/zuul/zuul-jobs/src/branch/master/test-playbooks/python/tox.yaml#L54-L7723:19
clarkband it is passing in a tempfile as an argument and that is simply echoing to files with bash then confirming the outputs? Yes I think we just need any small package to see that it installs something23:20
corvusi'm writing a change for requestsexceptions23:20
clarkbcool23:20
corvus(well, specifically, i'm writing a commit message)23:20
fungithinking back, the reason i added tox-bindep there was because that was the specific addition which was failing tox jobs in some project23:20
fungitrying to find the discussion to confirm23:20
opendevreviewJames E. Blair proposed zuul/zuul-jobs master: Avoid tox-bindep in test-tox job  https://review.opendev.org/c/zuul/zuul-jobs/+/86694523:24
fungiokay, it was related to this revert: https://review.opendev.org/c/zuul/zuul-jobs/+/81200123:24
clarkbfungi: https://github.com/tox-dev/tox/commit/554bd0a84391f6648136fe747b77bf22e408b02b they fixed the faq around disabling colors23:24
funginice!23:24
clarkbcorvus: oh wait requires is special23:25
clarkbcorvus: https://tox.wiki/en/latest/config.html#core23:25
clarkbcorvus: a better package may be virtualenv?23:25
clarkboh it will provision a new env though so ya requestexceptions is fine23:26
clarkbsorry for the noise I just had to digest this a bit23:26
corvusyeah, i didn't know about it being special, but i agree, after learning that, requestsexceptions should still work for us23:26
clarkbI understand the issue on the v4 flip too23:28
fungihttps://meetings.opendev.org/irclogs/%23openstack-infra/%23openstack-infra.2021-09-30.log.html#t2021-09-30T17:42:29 confirms the example was based on one found "in the wild" in openstack/tripleo-quickstart-extras23:28
fungiso i'm quite sure it was just chosen for convenience23:29
clarkbtox v4 is enforcing that posargs come after -- and the test there doesn't do that23:29
fungino special reason not to swap it out23:29
clarkbthis is anyhting thing that users will need to address23:29
opendevreviewClark Boylan proposed zuul/zuul-jobs master: Flip ensure-tox to tox v4 by default  https://review.opendev.org/c/zuul/zuul-jobs/+/86694323:29
clarkbthat patchset illustrates what I mean re --23:30
clarkbhopefully it makes sense23:30
clarkbI meant to say the -- requirement is *another thing* not anything users will need to address23:32
corvusclarkb: now that we understand that requires does a nested env -- i think my change may need to be squashed with your v3-compat change23:32
corvus(because it fails zuul-job-test-tox with the command line argument failure)23:33
corvuser, your v4-compat change23:33
corvusi dunno, one of your changes :)23:33
clarkbcorvus: I think my v4 change may work because I'm pinning tox to the old compat version in the nested env23:34
clarkbcorvus: if you wnt to squash them together or put them in order I don't think that hurts either23:34
corvusoh yeah, i think we should try to avoid pinning that, it's probably a time bomb23:35
corvusi'll rebase my change onto the end of your stack though23:35
clarkbsounds good23:35
fungibut yeah, for example tripleo-quickstart-extras won't be able to switch to tox v4 without either dropping their use of tox-bindep or getting tox v4 support implemented in tox-bindep23:35
opendevreviewJames E. Blair proposed zuul/zuul-jobs master: Avoid tox-bindep in test-tox job  https://review.opendev.org/c/zuul/zuul-jobs/+/86694523:36
clarkbfungi: ya23:36
corvusclarkb: https://zuul.opendev.org/t/zuul/build/e04140c2864e4a88bbd0efe1e87ac07d waah23:43
corvusclarkb: i feel like i'm not seeing the "--" i expect to see in the logs23:44
clarkbya maybe I didn't identify all the places we do that?23:44
clarkbya there are two tempfiles...23:45
ianwanyone who's not a newcomer like me know what  https://opendev.org/opendev/system-config/src/branch/master/playbooks/zuul/gerrit/files/static/system-cla.html is for?23:45
fungiianw: so that our machine accounts don't need a signed cla to push changes23:47
fungie.g. the proposal bot23:47
opendevreviewClark Boylan proposed zuul/zuul-jobs master: Flip ensure-tox to tox v4 by default  https://review.opendev.org/c/zuul/zuul-jobs/+/86694323:48
opendevreviewClark Boylan proposed zuul/zuul-jobs master: Avoid tox-bindep in test-tox job  https://review.opendev.org/c/zuul/zuul-jobs/+/86694523:48
clarkbcorvus: ^ hopefully that is it23:48
fungiianw: once upon a time the icla had to match up to foundation memberships and it was a way around needing to have fake people associated with such accounts23:49
clarkbwow https://github.com/tox-dev/tox/issues/2622#issuecomment-134176145323:49
clarkbmany tools consider stderr a failure. I just I don't ok23:51
clarkbI give up23:51
corvusclarkb: what do you know about ci tools?23:51
corvusi'm happy to review nox implementation changes23:52
clarkbassuming the dust has settled tomorrow I do intend on trying to track down those nodepool issues23:54
clarkbcorvus: I WIP'd https://review.opendev.org/c/zuul/zuul-jobs/+/866943 os that it doesn't land early23:55
ianwfungi: thanks.  just thinking about the submit-requirements, and how we might test it23:57
clarkbianw: my day started by looking into the crio failures for this nodepool change's functional k8s job https://review.opendev.org/c/zuul/nodepool/+/86263023:57
clarkbianw: that led me to https://review.opendev.org/c/zuul/zuul-jobs/+/866920 but things had exploded by then23:57
clarkbianw: any chance this is familiar to you as you set up the crio on jammy stuff?23:57
ianwEmail: devel\x3akubic@build.opensuse.org23:58
ianwThis key has expired23:58
ianwi think maybe the root of it is the kubic repo key has ... expired23:59
clarkboh!23:59
ianwnot that https://zuul.opendev.org/t/zuul/build/0e4d02d655e54f9b85e44e0a7cc9c619/console#1/0/111/ubuntu-jammy really says that23:59

Generated by irclog2html.py 2.17.3 by Marius Gedminas - find it at https://mg.pov.lt/irclog2html/!