Friday, 2022-08-26

opendevreviewTony Breeds proposed openstack/project-config master: Update timer settings to match docs  https://review.opendev.org/c/openstack/project-config/+/85386301:08
*** rlandy is now known as rlandy|out01:33
*** dviroel|rover is now known as dviroel|out01:37
tonybSo that ^^ is failing with a linter error that looks verymuch like it isn't my fault.  Any pointers to a fix would be gladly accepted01:41
tonybhttps://zuul.opendev.org/t/openstack/build/2482a07cd4b549f18aba4f2a99d1f137/log/job-output.txt#1137 is the error?01:42
*** ysandeep|out is now known as ysandeep02:21
fungitonyb: ugh, ansible-lint 6.5.102:37
fungii think my !=6.5.0 was optimistic02:38
tonybfungi: Should I update it to '< 6.5.0' ?02:39
fungitonyb: well, if you look at the commit message from my last update to the tox.ini it references a regression which was filed02:40
tonybfungi: Okay  I'll go look02:40
fungiideally we'd find out what's now regressed in 6.5.1 (if anything) and decide whether to block this version also or just give up and cap it02:40
fungiit's too late for me to really look into it though02:41
fungiianw might also have some ideas if he's not busy02:41
tonybIt's the same issue the fix is still in draft  If I'm reading correctly02:43
* fungi sighs02:43
fungitonyb: if you want to propose to block this version too, i can fast approve02:45
opendevreviewTony Breeds proposed openstack/project-config master: Update timer settings to match docs  https://review.opendev.org/c/openstack/project-config/+/85386302:46
opendevreviewTony Breeds proposed openstack/project-config master: Exclude ansible-lint 6.5.1 also.  https://review.opendev.org/c/openstack/project-config/+/85470102:46
tonybdone. I can ping you when I see results from zuul02:47
fungialready approved, so will merge if zuul wills it02:48
tonybfungi: torommow, I'd like to talk to you about running 'tox' in project-config I get very strange issues so I can't validate things locally02:48
tonybfungi: Thanks. :)02:48
* tonyb is rather happy to be "back" and working with this awesome community02:48
fungii don't do it often run tox locally for project-config, but i believe you may end up with some dirty cache locally which benefits from a git clean02:49
fungiand yes, let's do brainstorm how to improve local tox for it02:49
fungi(when i'm not headed to sleep that is)02:50
tonybSounds good02:57
opendevreviewMerged openstack/project-config master: Exclude ansible-lint 6.5.1 also.  https://review.opendev.org/c/openstack/project-config/+/85470103:15
opendevreviewMerged openstack/project-config master: Update timer settings to match docs  https://review.opendev.org/c/openstack/project-config/+/85386303:15
ianwsorry was distracted -- thanks fungi03:35
*** soniya29|ruck is now known as soniya2904:56
*** jpena|off is now known as jpena07:52
*** ysandeep is now known as ysandeep|away08:18
*** rlandy|out is now known as rlandy10:30
*** ysandeep|away is now known as ysandeep10:53
ade_leefungi, clarkb - got this on one of our gate jobs -- https://zuul.opendev.org/t/openstack/build/2afa50adebea4137a43d0892103ebe5711:22
ade_leeI rechecked - but I hadn't seen that before11:22
*** ysandeep is now known as ysandeep|afk11:23
*** dviroel|out is now known as dviroel11:23
*** ysandeep|afk is now known as ysandeep11:36
*** sean-k-mooney1 is now known as sean-k-mooney11:47
*** ysandeep is now known as ysandeep|afk12:05
opendevreviewdaniel.pawlik proposed openstack/ci-log-processing master: Remove deprecated document type  https://review.opendev.org/c/openstack/ci-log-processing/+/85477612:47
fungiade_lee: usually that's a rogue vm in the provider squatting the same ip address as the job node. if we continue to see failures like that involving 104.130.169.189 we can let rackspace know there's a problem vm somewhere in their iad region, but i think they have some automated process to clean those up so it may not resurface12:57
fungii can't imagine anything in the job causing the ssh host key to change between creating the pdf and fetching it anyway12:57
ade_leeyup - just wanted to let you guys know in case anything nefarious is going on13:00
opendevreviewMerged openstack/ci-log-processing master: Remove deprecated document type  https://review.opendev.org/c/openstack/ci-log-processing/+/85477613:22
opendevreviewBrian Rosmaita proposed openstack/project-config master: Make Review-Priority completely sticky  https://review.opendev.org/c/openstack/project-config/+/85478113:34
opendevreviewBrian Rosmaita proposed openstack/project-config master: [glance] Make Review-Priority completely sticky  https://review.opendev.org/c/openstack/project-config/+/85478113:34
rosmaitafungi: can you look at ^^ to make sure it will do what i describe in the commit message?13:35
efoleyHi folks, I have a job failure due to expired certificates: https://zuul.opendev.org/t/openstack/build/d61814d568f6430faa7bc55b433931b4. Can someone take a look for me? I've see the same job pass on different changes today, so I'm thinking it's not an issue with the job.13:49
JayFefoley: looks like a random fedora mirror in the rotation is broken, not any part of openstack/opendev infra14:03
JayFefoley: a recheck should be able to resolve it, if you're concerned you can report to upstream fedora they have a failed mirror14:03
*** dasm|off is now known as dasm14:04
*** njohnston_ is now known as njohnston14:05
efoleyJayF: Okie dokie, thanks for taking a look!14:07
opendevreviewBrian Rosmaita proposed openstack/project-config master: [glance] Make Review-Priority completely sticky  https://review.opendev.org/c/openstack/project-config/+/85478114:13
*** ysandeep|afk is now known as ysandeep|out14:22
*** jpena is now known as jpena|off14:29
opendevreviewBrian Rosmaita proposed openstack/project-config master: [glance] Make Review-Priority completely sticky  https://review.opendev.org/c/openstack/project-config/+/85478114:32
fungirosmaita: i'm on the road today and working with extremely low bandwidth/lossy wireless modem connection so can't easily check against the gerrit docs presently14:56
rosmaitafungi: no problem, it's a low-priority thing14:56
fungia low-priority priority thing ;)14:58
*** dviroel is now known as dviroel|lunch15:00
opendevreviewBrian Rosmaita proposed openstack/project-config master: [glance] Make Review-Priority completely sticky  https://review.opendev.org/c/openstack/project-config/+/85478115:03
fungirosmaita: revisiting the docs, i think just copyAnyScore should suffice. do you have reason to believe overriding the default copyCondition is warranted? this would be the first acl in our corpus to do that, if so15:23
fungia number of acls use copyAnyScore = true (mainly for their own review priority implementations)15:24
fungidocumentation for copyAnyScore states "any score for the label is copied forward when a new patch set is uploaded"15:26
fungiwhich sounds like exactly what you want15:26
rosmaitafungi: well, i figured copyAnyScore should work like copyMaxScore and copyMinScore, i.e., would only do the copy when some condition is met15:32
rosmaitamy reading is that copyMaxScore means that a +2 is sticky, copyMinScore means that a -1 is sticky, and i want +1 to be sticky too15:32
fungii guess you could check whether one of the repos already using copyAnyScore is working the way you expect or is working the way you want15:34
rosmaitaok, i will look into it, but i think its always used in conjunction with copyAllScoresIfNoCodeChange and/or copyAllScoresOnTrivialRebase15:35
rosmaitaand i am wrong about that, nova just has plain copyAnyScore15:37
fungiyeah, that's one of the ones i was comparing to15:47
rosmaitalooking at their values, not sure they care if it's sticky across patch sets or not15:48
*** frenzyfriday is now known as frenzyfriday|pto15:48
rosmaitai will check with dansmith or somebody to see how it works15:48
fungiyou can probably tell by looking at a change where a review priority is set and unhiding all the comment activity, then see if the scores were set on earlier patchsets and still showing up without being readded15:49
fungibut yeah, it may be easier to just ask someone who's a regular on one of those projects15:50
fungimainly, it's that i would be mildly surprised if what glance needs is something no other project is already doing, so want to avoid unnecessarily complicating glance's acl15:51
rosmaitaoh, yeah, i get that15:51
rosmaitafungi: not sure i am reading this correctly, but it looks like gibi set Review-Priority +2 on PS 14, and then had to set it again for PS15:59
rosmaita16 on this review: https://review.opendev.org/c/openstack/nova/+/778347/15:59
dansmithtbh, I'm such an old timer that I haven't really integrated RP into my workflow16:05
dansmithso I'm maybe not the right person to ask16:05
dansmiththat said, I'd definitely think that RP being sticky across revisions makes sense16:05
dansmithI think RP is intended to be "this thing is a priority this cycle" and not "this thing is a priority today"16:06
*** dviroel|lunch is now known as dviroel16:10
rosmaitafungi: ok, dansmith did a quick test, looks like Review-Priority is sticky with just copyAnyScore16:12
opendevreviewBrian Rosmaita proposed openstack/project-config master: [glance] Make Review-Priority completely sticky  https://review.opendev.org/c/openstack/project-config/+/85478116:14
fungirosmaita: awesome, thanks for checking!17:05
opendevreviewMerged openstack/project-config master: [glance] Make Review-Priority completely sticky  https://review.opendev.org/c/openstack/project-config/+/85478117:12
tonybfungi: If you have some time cna we look at tox (specifically linters) in project-config?18:44
tonybI'm runninf F35 (python 3.10) and when I fun tox I get what python errors?18:44
tonybhttps://paste.opendev.org/show/bDduInzm8Nv2G1HnH7ak/18:44
tonybIf I chnage the python version I get different issues18:45
clarkbtonyb: base python is set to python3 but that print statement is never python3 compatible19:15
clarkbare you getting a weird dependency resolution for flake8 maybe?19:16
tonybI'm 95% sure I get the same version as the gate19:16
tonybI did notice that the linter job is running /home/zuul/.local/bin/python319:17
tonybwhat is that?19:17
clarkbflake8-3.8.4-py2.py3-none-any.whl is the version the gate installs19:17
clarkbtonyb: .local is where pip does user installs to iirc. So tox is installed via pip --user?19:17
clarkbI'm confused because it really looks like flake8 is dynamically giving python3 a python2 print string19:18
tonyb[tony@thor project-config]$ .tox/linters/bin/pip3 freeze | grep flake19:19
tonybflake8==3.8.419:19
tonybpyflakes==2.2.019:19
clarkbwhich seems to come from https://opendev.org/opendev/system-config/src/branch/master/tools/delete-gerrit-spam.py#L5219:19
clarkbwhy would flake8 do that?19:19
tonybclarkb: Yeah it's so confusing and doubly so as it is very different in the gate19:19
clarkbI think the issue is that flake8 must not support python2 at all anymore and for some reason when y ou run it is finding python2 scripts and exploding. but it doesn't fine them in the gate?19:21
clarkbcould it be a flake8 + python3.10 specific issue? like maybe the old python3 ast libs would have apython2 mode?19:23
clarkb(I doubt that though)19:23
fungiokay, finally got home and ate. trying tox -e linters with python 3.10 in openstack/project-config19:29
fungithe fact that it installs ansible may be part of the reason i don't run it locally. at least in the past ansible dragged in all manner of additional deps and either took forever or filled up my available disk19:30
fungiokay, got it to run, and can confirm i see the same error as tonyb19:31
clarkbfungi: if you have 3.8 installed does it do the same?19:31
clarkb3.8 is what the gate is using I think19:31
clarkbya confirmed 3.8 in the gate19:31
fungitrying again with basepython=3.919:31
fungibut will try 3.8 after that19:31
fungiokay, under 3.8 i get tons of ansible-lint complaints19:37
fungier, 3.9 i mean19:37
tonybfungi: Yeah 3.8 is *better* and makes it to ansible lint19:38
fungi3.9 also got ansible-lint running for me19:38
fungi3.8 looks the same19:39
fungione thing i notice is ansible-lint is checking things in .cache19:39
fungiwhich is in the exclude_paths list in .ansible-lint19:40
fungiso i suspect something is causing it not to respect that19:40
clarkbmaybe it is a change to the python ast lib under 3.10 then19:41
fungithe comment in tox.ini for testenv:linters seems to indicate some significant differences between zuul execution and local runs19:41
fungioh, i think our finds may be overriding the exclusions19:42
fungior aren't actually anchoring ansible-lint base dir19:43
fungino, wait, i see the problem19:45
fungithat's not coming from ansible-lint it's coming from flake819:45
fungifor local runs we checkout a bunch of repos into .cache for ansible-lint to reference later, then we run flake8 without telling it to skip .cache19:46
fungiwe don't hit that in the gate because we don't use .cache for the other repos we need, instead zuul checks them out into parallel directories19:47
clarkbah19:47
clarkbwhere are the flake8 skips?19:47
funginear the end of tox.ini, i'm trying with .cache added to it now19:48
fungiseems to have made it past flake8 now, at least19:49
fungilinters: commands succeeded19:49
fungiokay, i'll get a patch pushed up for that momentarily19:49
clarkbI guess there could still be a python change but that wasn't the root cause19:49
fungifirst, trying again with python 3.10 to see if that also solved the problem there19:50
fungiyeah, seems to19:50
fungisucceeded completely with Python 3.10.619:51
opendevreviewJeremy Stanley proposed openstack/project-config master: Exclude .cache when running flake8  https://review.opendev.org/c/openstack/project-config/+/85484219:54
fungitonyb: clarkb: ^ that should do it19:54
tonybLOL I just wrote the same patch ;P19:54
fungithen one of us should be well qualified to review the other's patch now ;)20:00
tonyb:)20:01
tonybI don't know if this is a generic opendev question or openstack ... but are there basic python containers usable in the gate already?20:03
fungibasic python containers of what?20:04
tonyb.. python?  no specific app or library.20:06
fungido you mean like using containers as an environment for tests, or as a base image for container image building? or something else entirely?20:06
tonybI'm musing on using a containerised python to "expand" constraint generation20:06
fungioh, i still think the problem with the constraints job is that there's only one. we should run it separately for each python version we want it to support and then, if desired, concatenate the results of all those20:07
tonybfungi: Sure that'd work.  The job already runs mutiple versions of python (or at least can)20:08
tonybwe could easily do what your suggesting20:08
fungithere's no reason that data needs to all be generated from a single job run, and most of its complexity stems from trying to shoehorn multiple python interpreter versions into a single build20:09
tonyb*if* we had an easy acceptable way to get several versions of python (other than whatever the OS provides)20:09
tonybYup.20:09
clarkbtonyb: opendev builds images based on https://hub.docker.com/_/python using the debian variants (we found that musl and python don't play nice on alpine)20:10
fungiopenstack decides what versions of python it will support for a release based on which platforms we're testing it on, so it seems odd that we'd try to reengineer a custom platform which has all of those versions instead of using the platforms openstack says it's supporting20:10
clarkbya I'm not sure it is the right choice, just wanted to point out nothign stops anyone from using existing containers. opendev does it to great effect20:11
tonybclarkb: Can you point me at the Containerfiles?20:11
clarkbtonyb: https://opendev.org/opendev/system-config/src/branch/master/docker/python-base/Dockerfile and https://opendev.org/opendev/system-config/src/branch/master/docker/python-builder/Dockerfile the builder is a throw away base image to "compile" the python project and all its deps into wheels. Then we copy the wheels from the builder to an image based on -base and install20:12
clarkbthem. This keeps the final result small (avoids compile artifacts and build time deps in the final image)20:12
fungibut a multi-build solution could basically have a job which runs the script on ubuntu-jammy and another which runs the script on debian-bullseye, each of them returning their respective constraints files as artifacts, and then a final job could run to grab those artifacts and propose them (optionally concatenating with sort -u or whatever you like)20:12
clarkbhttps://opendev.org/zuul/zuul/src/branch/master/Dockerfile shows consumption of them20:13
tonybfungi: I mostly agree, I'm looking kinda musing out loud20:13
clarkbThere isn't really anything special about the images we build. We do try to take care to avoid extra unneeded content in the final image though20:13
tonybfungi: Oh yeah that's totally true.  Different nodesets would work well20:13
tonybclarkb: awesome20:14
fungiyou could do it with a multi-node job where each node was a different platform too, but this doesn't really need to even all be done with a single job, it can be dependent jobs in the same buildset for a bit of added flexibility20:15
tonybYeah.  I'm liking this idea20:16
tonybI'll try and do it for antelope20:16
fungiin my view, zuul is already providing the execution environments we need to generate constraints for different python interpreter versions, so it makes the most sense just to use those instead of trying to build new execution environments in containers ontop of one of the existing execution environments. it's a lot of added baggage20:17
fungimerging the results into something essentially equivalent to the current proposals should be fairly straightforward regardless20:18
opendevreviewMerged openstack/project-config master: Exclude .cache when running flake8  https://review.opendev.org/c/openstack/project-config/+/85484220:19
clarkbI agree that the way openstack defines supported platforms today doesn't work well with the upstream python images. That said python 3.10 and 3.11 bring pretty major performance improvements to python and being able to really quickly update our systems to them (3.11 still pending) has been great20:20
clarkbI think corvus said zuul unit test time was cut in half locally between 3.9 and 3.1020:21
fungii'm not surprised20:24
*** dasm is now known as dasm|off21:07
*** dviroel is now known as dviroel|afk22:31
*** dviroel|afk is now known as dviroel22:58
*** dviroel is now known as dviroel|out23:01

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