opendevreview | Tony Breeds proposed openstack/project-config master: Update timer settings to match docs https://review.opendev.org/c/openstack/project-config/+/853863 | 01:08 |
---|---|---|
*** rlandy is now known as rlandy|out | 01:33 | |
*** dviroel|rover is now known as dviroel|out | 01:37 | |
tonyb | So that ^^ is failing with a linter error that looks verymuch like it isn't my fault. Any pointers to a fix would be gladly accepted | 01:41 |
tonyb | https://zuul.opendev.org/t/openstack/build/2482a07cd4b549f18aba4f2a99d1f137/log/job-output.txt#1137 is the error? | 01:42 |
*** ysandeep|out is now known as ysandeep | 02:21 | |
fungi | tonyb: ugh, ansible-lint 6.5.1 | 02:37 |
fungi | i think my !=6.5.0 was optimistic | 02:38 |
tonyb | fungi: Should I update it to '< 6.5.0' ? | 02:39 |
fungi | tonyb: well, if you look at the commit message from my last update to the tox.ini it references a regression which was filed | 02:40 |
tonyb | fungi: Okay I'll go look | 02:40 |
fungi | ideally 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 it | 02:40 |
fungi | it's too late for me to really look into it though | 02:41 |
fungi | ianw might also have some ideas if he's not busy | 02:41 |
tonyb | It's the same issue the fix is still in draft If I'm reading correctly | 02:43 |
* fungi sighs | 02:43 | |
fungi | tonyb: if you want to propose to block this version too, i can fast approve | 02:45 |
opendevreview | Tony Breeds proposed openstack/project-config master: Update timer settings to match docs https://review.opendev.org/c/openstack/project-config/+/853863 | 02:46 |
opendevreview | Tony Breeds proposed openstack/project-config master: Exclude ansible-lint 6.5.1 also. https://review.opendev.org/c/openstack/project-config/+/854701 | 02:46 |
tonyb | done. I can ping you when I see results from zuul | 02:47 |
fungi | already approved, so will merge if zuul wills it | 02:48 |
tonyb | fungi: 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 locally | 02:48 |
tonyb | fungi: Thanks. :) | 02:48 |
* tonyb is rather happy to be "back" and working with this awesome community | 02:48 | |
fungi | i 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 clean | 02:49 |
fungi | and yes, let's do brainstorm how to improve local tox for it | 02:49 |
fungi | (when i'm not headed to sleep that is) | 02:50 |
tonyb | Sounds good | 02:57 |
opendevreview | Merged openstack/project-config master: Exclude ansible-lint 6.5.1 also. https://review.opendev.org/c/openstack/project-config/+/854701 | 03:15 |
opendevreview | Merged openstack/project-config master: Update timer settings to match docs https://review.opendev.org/c/openstack/project-config/+/853863 | 03:15 |
ianw | sorry was distracted -- thanks fungi | 03:35 |
*** soniya29|ruck is now known as soniya29 | 04:56 | |
*** jpena|off is now known as jpena | 07:52 | |
*** ysandeep is now known as ysandeep|away | 08:18 | |
*** rlandy|out is now known as rlandy | 10:30 | |
*** ysandeep|away is now known as ysandeep | 10:53 | |
ade_lee | fungi, clarkb - got this on one of our gate jobs -- https://zuul.opendev.org/t/openstack/build/2afa50adebea4137a43d0892103ebe57 | 11:22 |
ade_lee | I rechecked - but I hadn't seen that before | 11:22 |
*** ysandeep is now known as ysandeep|afk | 11:23 | |
*** dviroel|out is now known as dviroel | 11:23 | |
*** ysandeep|afk is now known as ysandeep | 11:36 | |
*** sean-k-mooney1 is now known as sean-k-mooney | 11:47 | |
*** ysandeep is now known as ysandeep|afk | 12:05 | |
opendevreview | daniel.pawlik proposed openstack/ci-log-processing master: Remove deprecated document type https://review.opendev.org/c/openstack/ci-log-processing/+/854776 | 12:47 |
fungi | ade_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 resurface | 12:57 |
fungi | i can't imagine anything in the job causing the ssh host key to change between creating the pdf and fetching it anyway | 12:57 |
ade_lee | yup - just wanted to let you guys know in case anything nefarious is going on | 13:00 |
opendevreview | Merged openstack/ci-log-processing master: Remove deprecated document type https://review.opendev.org/c/openstack/ci-log-processing/+/854776 | 13:22 |
opendevreview | Brian Rosmaita proposed openstack/project-config master: Make Review-Priority completely sticky https://review.opendev.org/c/openstack/project-config/+/854781 | 13:34 |
opendevreview | Brian Rosmaita proposed openstack/project-config master: [glance] Make Review-Priority completely sticky https://review.opendev.org/c/openstack/project-config/+/854781 | 13:34 |
rosmaita | fungi: can you look at ^^ to make sure it will do what i describe in the commit message? | 13:35 |
efoley | Hi 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 |
JayF | efoley: looks like a random fedora mirror in the rotation is broken, not any part of openstack/opendev infra | 14:03 |
JayF | efoley: a recheck should be able to resolve it, if you're concerned you can report to upstream fedora they have a failed mirror | 14:03 |
*** dasm|off is now known as dasm | 14:04 | |
*** njohnston_ is now known as njohnston | 14:05 | |
efoley | JayF: Okie dokie, thanks for taking a look! | 14:07 |
opendevreview | Brian Rosmaita proposed openstack/project-config master: [glance] Make Review-Priority completely sticky https://review.opendev.org/c/openstack/project-config/+/854781 | 14:13 |
*** ysandeep|afk is now known as ysandeep|out | 14:22 | |
*** jpena is now known as jpena|off | 14:29 | |
opendevreview | Brian Rosmaita proposed openstack/project-config master: [glance] Make Review-Priority completely sticky https://review.opendev.org/c/openstack/project-config/+/854781 | 14:32 |
fungi | rosmaita: 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 presently | 14:56 |
rosmaita | fungi: no problem, it's a low-priority thing | 14:56 |
fungi | a low-priority priority thing ;) | 14:58 |
*** dviroel is now known as dviroel|lunch | 15:00 | |
opendevreview | Brian Rosmaita proposed openstack/project-config master: [glance] Make Review-Priority completely sticky https://review.opendev.org/c/openstack/project-config/+/854781 | 15:03 |
fungi | rosmaita: 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 so | 15:23 |
fungi | a number of acls use copyAnyScore = true (mainly for their own review priority implementations) | 15:24 |
fungi | documentation for copyAnyScore states "any score for the label is copied forward when a new patch set is uploaded" | 15:26 |
fungi | which sounds like exactly what you want | 15:26 |
rosmaita | fungi: well, i figured copyAnyScore should work like copyMaxScore and copyMinScore, i.e., would only do the copy when some condition is met | 15:32 |
rosmaita | my reading is that copyMaxScore means that a +2 is sticky, copyMinScore means that a -1 is sticky, and i want +1 to be sticky too | 15:32 |
fungi | i guess you could check whether one of the repos already using copyAnyScore is working the way you expect or is working the way you want | 15:34 |
rosmaita | ok, i will look into it, but i think its always used in conjunction with copyAllScoresIfNoCodeChange and/or copyAllScoresOnTrivialRebase | 15:35 |
rosmaita | and i am wrong about that, nova just has plain copyAnyScore | 15:37 |
fungi | yeah, that's one of the ones i was comparing to | 15:47 |
rosmaita | looking at their values, not sure they care if it's sticky across patch sets or not | 15:48 |
*** frenzyfriday is now known as frenzyfriday|pto | 15:48 | |
rosmaita | i will check with dansmith or somebody to see how it works | 15:48 |
fungi | you 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 readded | 15:49 |
fungi | but yeah, it may be easier to just ask someone who's a regular on one of those projects | 15:50 |
fungi | mainly, 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 acl | 15:51 |
rosmaita | oh, yeah, i get that | 15:51 |
rosmaita | fungi: 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 PS | 15:59 |
rosmaita | 16 on this review: https://review.opendev.org/c/openstack/nova/+/778347/ | 15:59 |
dansmith | tbh, I'm such an old timer that I haven't really integrated RP into my workflow | 16:05 |
dansmith | so I'm maybe not the right person to ask | 16:05 |
dansmith | that said, I'd definitely think that RP being sticky across revisions makes sense | 16:05 |
dansmith | I 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 dviroel | 16:10 | |
rosmaita | fungi: ok, dansmith did a quick test, looks like Review-Priority is sticky with just copyAnyScore | 16:12 |
opendevreview | Brian Rosmaita proposed openstack/project-config master: [glance] Make Review-Priority completely sticky https://review.opendev.org/c/openstack/project-config/+/854781 | 16:14 |
fungi | rosmaita: awesome, thanks for checking! | 17:05 |
opendevreview | Merged openstack/project-config master: [glance] Make Review-Priority completely sticky https://review.opendev.org/c/openstack/project-config/+/854781 | 17:12 |
tonyb | fungi: If you have some time cna we look at tox (specifically linters) in project-config? | 18:44 |
tonyb | I'm runninf F35 (python 3.10) and when I fun tox I get what python errors? | 18:44 |
tonyb | https://paste.opendev.org/show/bDduInzm8Nv2G1HnH7ak/ | 18:44 |
tonyb | If I chnage the python version I get different issues | 18:45 |
clarkb | tonyb: base python is set to python3 but that print statement is never python3 compatible | 19:15 |
clarkb | are you getting a weird dependency resolution for flake8 maybe? | 19:16 |
tonyb | I'm 95% sure I get the same version as the gate | 19:16 |
tonyb | I did notice that the linter job is running /home/zuul/.local/bin/python3 | 19:17 |
tonyb | what is that? | 19:17 |
clarkb | flake8-3.8.4-py2.py3-none-any.whl is the version the gate installs | 19:17 |
clarkb | tonyb: .local is where pip does user installs to iirc. So tox is installed via pip --user? | 19:17 |
clarkb | I'm confused because it really looks like flake8 is dynamically giving python3 a python2 print string | 19:18 |
tonyb | [tony@thor project-config]$ .tox/linters/bin/pip3 freeze | grep flake | 19:19 |
tonyb | flake8==3.8.4 | 19:19 |
tonyb | pyflakes==2.2.0 | 19:19 |
clarkb | which seems to come from https://opendev.org/opendev/system-config/src/branch/master/tools/delete-gerrit-spam.py#L52 | 19:19 |
clarkb | why would flake8 do that? | 19:19 |
tonyb | clarkb: Yeah it's so confusing and doubly so as it is very different in the gate | 19:19 |
clarkb | I 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 |
clarkb | could 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 |
fungi | okay, finally got home and ate. trying tox -e linters with python 3.10 in openstack/project-config | 19:29 |
fungi | the 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 disk | 19:30 |
fungi | okay, got it to run, and can confirm i see the same error as tonyb | 19:31 |
clarkb | fungi: if you have 3.8 installed does it do the same? | 19:31 |
clarkb | 3.8 is what the gate is using I think | 19:31 |
clarkb | ya confirmed 3.8 in the gate | 19:31 |
fungi | trying again with basepython=3.9 | 19:31 |
fungi | but will try 3.8 after that | 19:31 |
fungi | okay, under 3.8 i get tons of ansible-lint complaints | 19:37 |
fungi | er, 3.9 i mean | 19:37 |
tonyb | fungi: Yeah 3.8 is *better* and makes it to ansible lint | 19:38 |
fungi | 3.9 also got ansible-lint running for me | 19:38 |
fungi | 3.8 looks the same | 19:39 |
fungi | one thing i notice is ansible-lint is checking things in .cache | 19:39 |
fungi | which is in the exclude_paths list in .ansible-lint | 19:40 |
fungi | so i suspect something is causing it not to respect that | 19:40 |
clarkb | maybe it is a change to the python ast lib under 3.10 then | 19:41 |
fungi | the comment in tox.ini for testenv:linters seems to indicate some significant differences between zuul execution and local runs | 19:41 |
fungi | oh, i think our finds may be overriding the exclusions | 19:42 |
fungi | or aren't actually anchoring ansible-lint base dir | 19:43 |
fungi | no, wait, i see the problem | 19:45 |
fungi | that's not coming from ansible-lint it's coming from flake8 | 19:45 |
fungi | for 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 .cache | 19:46 |
fungi | we 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 directories | 19:47 |
clarkb | ah | 19:47 |
clarkb | where are the flake8 skips? | 19:47 |
fungi | near the end of tox.ini, i'm trying with .cache added to it now | 19:48 |
fungi | seems to have made it past flake8 now, at least | 19:49 |
fungi | linters: commands succeeded | 19:49 |
fungi | okay, i'll get a patch pushed up for that momentarily | 19:49 |
clarkb | I guess there could still be a python change but that wasn't the root cause | 19:49 |
fungi | first, trying again with python 3.10 to see if that also solved the problem there | 19:50 |
fungi | yeah, seems to | 19:50 |
fungi | succeeded completely with Python 3.10.6 | 19:51 |
opendevreview | Jeremy Stanley proposed openstack/project-config master: Exclude .cache when running flake8 https://review.opendev.org/c/openstack/project-config/+/854842 | 19:54 |
fungi | tonyb: clarkb: ^ that should do it | 19:54 |
tonyb | LOL I just wrote the same patch ;P | 19:54 |
fungi | then one of us should be well qualified to review the other's patch now ;) | 20:00 |
tonyb | :) | 20:01 |
tonyb | I 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 |
fungi | basic python containers of what? | 20:04 |
tonyb | .. python? no specific app or library. | 20:06 |
fungi | do 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 |
tonyb | I'm musing on using a containerised python to "expand" constraint generation | 20:06 |
fungi | oh, 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 those | 20:07 |
tonyb | fungi: Sure that'd work. The job already runs mutiple versions of python (or at least can) | 20:08 |
tonyb | we could easily do what your suggesting | 20:08 |
fungi | there'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 build | 20:09 |
tonyb | *if* we had an easy acceptable way to get several versions of python (other than whatever the OS provides) | 20:09 |
tonyb | Yup. | 20:09 |
clarkb | tonyb: 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 |
fungi | openstack 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 supporting | 20:10 |
clarkb | ya 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 effect | 20:11 |
tonyb | clarkb: Can you point me at the Containerfiles? | 20:11 |
clarkb | tonyb: 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 install | 20:12 |
clarkb | them. This keeps the final result small (avoids compile artifacts and build time deps in the final image) | 20:12 |
fungi | but 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 |
clarkb | https://opendev.org/zuul/zuul/src/branch/master/Dockerfile shows consumption of them | 20:13 |
tonyb | fungi: I mostly agree, I'm looking kinda musing out loud | 20:13 |
clarkb | There 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 though | 20:13 |
tonyb | fungi: Oh yeah that's totally true. Different nodesets would work well | 20:13 |
tonyb | clarkb: awesome | 20:14 |
fungi | you 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 flexibility | 20:15 |
tonyb | Yeah. I'm liking this idea | 20:16 |
tonyb | I'll try and do it for antelope | 20:16 |
fungi | in 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 baggage | 20:17 |
fungi | merging the results into something essentially equivalent to the current proposals should be fairly straightforward regardless | 20:18 |
opendevreview | Merged openstack/project-config master: Exclude .cache when running flake8 https://review.opendev.org/c/openstack/project-config/+/854842 | 20:19 |
clarkb | I 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 great | 20:20 |
clarkb | I think corvus said zuul unit test time was cut in half locally between 3.9 and 3.10 | 20:21 |
fungi | i'm not surprised | 20:24 |
*** dasm is now known as dasm|off | 21:07 | |
*** dviroel is now known as dviroel|afk | 22:31 | |
*** dviroel|afk is now known as dviroel | 22:58 | |
*** dviroel is now known as dviroel|out | 23:01 |
Generated by irclog2html.py 2.17.3 by Marius Gedminas - find it at https://mg.pov.lt/irclog2html/!