| @tobias-urdin:matrix.org | Clark: Thanks! I was able to trace the logs with debug enabled and Zuul was indeed performing a merge when using Depends-On for a project specified in `job.required-projects` (with `override-checkout`) – it was a config/user error :) | 09:34 |
|---|---|---|
| -@gerrit:opendev.org- Fabien Boucher proposed: [zuul/zuul] 953415: Prevent Zuul to send docs to EL reporter if not connected https://review.opendev.org/c/zuul/zuul/+/953415 | 09:50 | |
| -@gerrit:opendev.org- Fabien Boucher proposed: [zuul/zuul] 953415: Prevent Zuul to send docs to EL reporter if not connected https://review.opendev.org/c/zuul/zuul/+/953415 | 09:58 | |
| @kacper_lysiak:matrix.org | Hi, I have an issue with the zuul-statsd metrics. | 11:08 |
| Specifically, the metric zuul_job_duration is documented as both a counter and a timer. Unfortunately the statsd-exporter does not allow setting the same 'match:' pattern for both metric types. | ||
| My question: is the only solution here to modify scheduler.py and split this metric into two separate ones? For example: | ||
| key1 = '%s.%s.result' and key2 = '%s.%s.duration' | ||
| @dfajfer:fsfe.org | kacper_lysiak: you mean this metric https://zuul-ci.org/docs/zuul/latest/monitoring.html#stat-zuul.tenant.%3Ctenant%3E.pipeline.%3Cpipeline%3E.project.%3Ccanonical_hostname%3E.%3Cproject%3E.%3Cbranch%3E.job.%3Cjobname%3E.%3Cresult%3E ? | 11:20 |
| @kacper_lysiak:matrix.org | fajfer @dfajfer:fsfe.org: yes | 11:25 |
| -@gerrit:opendev.org- Antoine Musso proposed: [zuul/zuul-jobs] 953441: upload-logs-s3: allow logging output on upload https://review.opendev.org/c/zuul/zuul-jobs/+/953441 | 12:53 | |
| -@gerrit:opendev.org- Antoine Musso proposed: [zuul/zuul-jobs] 953442: upload-logs-swift: allow logging output on upload https://review.opendev.org/c/zuul/zuul-jobs/+/953442 | 12:53 | |
| @amusso:matrix.org | I went to setup an upload-logs-swift and it fails without any error output due to the task having `no_logs: true`. 953442 (just above) would let one enable logging by setting `zuul_log_verbose: true` which certainly would help debugging | 14:27 |
| -@gerrit:opendev.org- James E. Blair https://matrix.to/#/@jim:acmegating.com proposed: [zuul/zuul] 953461: Launcher: improve upload logs https://review.opendev.org/c/zuul/zuul/+/953461 | 14:33 | |
| @jim:acmegating.com | Antoine Musso: we added the no_log there just in case something went wrong and the upload role ended up emitting a credential in the output. unfortunately, adding that as a zuul variable would let any untrusted job set that, and if they did that and such an error did occur, it would defeat our intent. having said that, we are becoming more comfortable with the idea that the upload role will probably not actually emit any credentials, even on an error. we're working on turning that off in a similar role that we're using with zuul-launcher (it has very limited use and a dedicated credential, so if we're wrong, the impact is small). if that goes well, i think we can do the same for the log upload role. | 14:38 |
| @jim:acmegating.com | Antoine Musso: in the mean time... you can make a local copy of that role, remove no_log, and refer to the local copy in order to debug the issue | 14:38 |
| @amusso:matrix.org | @corvus I would need the copy to be merged in my trusted config repo isn't it? | 14:40 |
| @jim:acmegating.com | Antoine Musso: yes | 14:48 |
| @amusso:matrix.org | That worked yes :) | 14:48 |
| @amusso:matrix.org | and I am going to abandon both of my changes from above | 14:49 |
| @jangutter:matrix.org | Hi folks, just checking if there's some weird trick I don't know about: is there a way to configure Zuul (either globally, or, preferably, per-tenant) to _ignore_ the standard zuul.yaml zuul.d/* .zuul.yaml .zuul.d/* and just use the extra-config-paths? (Alternatively, change them from being hardcoded). | 15:03 |
| If not, I'd be interested in trying to see if I could add that as a option. Haven't explored the code very deeply yet - I'd have to go slowly unpick where these are all hardcoded. | ||
| @jim:acmegating.com | jangutter: no, and i have doubts that we would merge a change like that. that was a very intentional design choice. can you elaborate on why you want that? | 15:05 |
| @jangutter:matrix.org | corvus: It's our standard "we run some internal forks" problem, but also we're exploring how to migrate between two instances of Zuul. I can see why hardcoding the paths is desireable - it can lead to some really hard to debug stuff if you get it wrong. (We're jumping quite a distance in Zuul versions, so we're doing something reasonably pathological). | 15:09 |
| -@gerrit:opendev.org- James E. Blair https://matrix.to/#/@jim:acmegating.com proposed: [zuul/zuul] 953469: Launcher: don't update upload timestamp https://review.opendev.org/c/zuul/zuul/+/953469 | 15:12 | |
| @jim:acmegating.com | jangutter: gotcha. then if you do end up writing something, i'd suggest just consider doing whatever you need for your internal fork and don't worry about generalizing it and targeting it for upstream. but one thing you could consider: move everything to "zuul-old-version.d/" and ignore zuul.yaml and friends by convention during your migration window. then when everything is done, move zuul-new-version.d/ to zuul.d/ etc. | 15:17 |
| @jangutter:matrix.org | corvus: that's the idea - basically during the migration treat one Zuul as an "external 3rd party CI". Aaah, migrations, the most expensive way to pay off tech debt. | 15:19 |
| @amusso:matrix.org | jangutter: I here you, we have started work to migrate our 8+years old Zuul 2.5 + Jenkins setup toward newer Zuul + Ansible :] | 17:05 |
| @amusso:matrix.org | RIP my vacations :b | 17:05 |
| -@gerrit:opendev.org- Clark Boylan proposed: [zuul/zuul] 952592: Set lower bounds on IBM and google cloud deps https://review.opendev.org/c/zuul/zuul/+/952592 | 17:31 | |
| @clarkb:matrix.org | its interesting how setting lower bounds on the ibm packages seems to make the google package resolution go crazy. Anyway I updated that change and hopefully the scope is sufficiently small pip will be happier now | 17:32 |
| -@gerrit:opendev.org- James E. Blair https://matrix.to/#/@jim:acmegating.com proposed: [zuul/nodepool] 953479: k8s: document minimal RBAC config https://review.opendev.org/c/zuul/nodepool/+/953479 | 17:34 | |
| @clarkb:matrix.org | thinking out loud here: I wonder if it makes sense to have the zuul launcher deps as extras as they are only needed by that one service (whereas most other deps are in use by all the services within zuul) | 17:39 |
| @clarkb:matrix.org | that might also help constrain the problem space but would potentially complicate the process of installing things | 17:39 |
| @clarkb:matrix.org | I guess disk space is cheap we just need to massage the dep solver and then we're good | 17:40 |
| @jim:acmegating.com | Clark: also, i would like to add them to the executor eventually, so i don't think we should over-optimize that. | 18:01 |
| @jim:acmegating.com | Clark: (also, also, technically the scheduler uses them too... but not to make any connections, just to load the libraries -- basically just so that openstacksdk can tell us (using configuration only) which image format is used by a given cloud) | 18:02 |
| -@gerrit:opendev.org- Clark Boylan proposed: [zuul/zuul] 952592: Set lower bounds on IBM and google cloud deps https://review.opendev.org/c/zuul/zuul/+/952592 | 18:03 | |
| @clarkb:matrix.org | oh I didn't know the scheduler was doing that. Then ya over optimizing seems like more trouble than its worth | 18:11 |
| -@gerrit:opendev.org- James E. Blair https://matrix.to/#/@jim:acmegating.com proposed: | 20:26 | |
| - [zuul/zuul] 953257: Launcher: fix restoring openstack delete state machine https://review.opendev.org/c/zuul/zuul/+/953257 | ||
| - [zuul/zuul] 953258: Launcher: fix restoring openstack create state machine https://review.opendev.org/c/zuul/zuul/+/953258 | ||
| - [zuul/zuul] 953482: Add state machine test to base cloud test and openstack https://review.opendev.org/c/zuul/zuul/+/953482 | ||
| -@gerrit:opendev.org- Clark Boylan proposed: [zuul/zuul] 952592: Set lower bounds on IBM, Google, and AWS cloud deps https://review.opendev.org/c/zuul/zuul/+/952592 | 20:29 | |
| -@gerrit:opendev.org- James E. Blair https://matrix.to/#/@jim:acmegating.com proposed: [zuul/zuul] 953496: Expose launcher locks thorugh the web api https://review.opendev.org/c/zuul/zuul/+/953496 | 22:20 | |
Generated by irclog2html.py 4.0.0 by Marius Gedminas - find it at https://mg.pov.lt/irclog2html/!