Friday, 2022-03-25

-@gerrit:opendev.org- Mohammed Naser proposed:00:03
- [zuul/zuul-jobs] 835162: ensure-kubernetes: fix missing 02-crio.conf https://review.opendev.org/c/zuul/zuul-jobs/+/835162
- [zuul/zuul-jobs] 835156: run-buildset-registry: Drop extra install packages task https://review.opendev.org/c/zuul/zuul-jobs/+/835156
-@gerrit:opendev.org- Dong Zhang proposed: [zuul/zuul] 834857: Fix bug in getting changed files https://review.opendev.org/c/zuul/zuul/+/83485707:01
-@gerrit:opendev.org- Dong Zhang proposed: [zuul/zuul] 834857: Fix bug in getting changed files https://review.opendev.org/c/zuul/zuul/+/83485707:03
-@gerrit:opendev.org- Zuul merged on behalf of Albin Vass: [zuul/zuul] 835074: Recover from broken process pools in merge operations https://review.opendev.org/c/zuul/zuul/+/83507407:39
-@gerrit:opendev.org- Zuul merged on behalf of Simon Westphahl: [zuul/nodepool] 835011: Don't yield to a provider with unsupported labels https://review.opendev.org/c/zuul/nodepool/+/83501107:40
-@gerrit:opendev.org- Albin Vass proposed: [zuul/zuul] 835019: Start zookeeper with users uid in test-setup-docker.sh https://review.opendev.org/c/zuul/zuul/+/83501907:45
-@gerrit:opendev.org- Dong Zhang proposed: [zuul/zuul] 834857: Fix bug in getting changed files https://review.opendev.org/c/zuul/zuul/+/83485709:38
@mhuin:matrix.orghey there, I'm just noticing a change in the build model, the status JSON used to hold "nodes_label", "node_name" and "worker" fields for each change, but not anymore12:40
@mhuin:matrix.orgis this intended? is there a new way to figure out which executor is handling a change?12:41
-@gerrit:opendev.org- Zuul merged on behalf of Matthieu Huin https://matrix.to/#/@mhuin:matrix.org: [zuul/zuul] 830846: GUI: fix broken enqueue when buildset.newrev is null https://review.opendev.org/c/zuul/zuul/+/83084613:41
@fungicide:matrix.orgmhu: i guess you meant "node_labels" but looks like that and node_name were dropped last july in https://review.opendev.org/798207 and then i think worker was dropped in october with https://review.opendev.org/81355214:30
@mhuin:matrix.orgfungi, so this is intentional then14:30
@fungicide:matrix.orgwell, i only skimmed the commit messages, but they do call out the removals of those attributes explicitly14:31
@mhuin:matrix.orga few days ago we had a situation where we had to drop buildsets being run on specific executors, we parsed the status json for workers and got our list that way14:32
@mhuin:matrix.org(we're still running 4.6)14:33
@mhuin:matrix.organother time, we had to dequeue all stalled buildsets in a given pipeline. So I was thinking of implementing a dequeue-all command for zuul-client that would run dequeues per pipeline and/or project and/or executor14:34
@mhuin:matrix.orgI guess we could still get the executor info from the finger gateway url, but would there be a strong opposition to re-adding the workers info to the status?14:36
@jim:acmegating.comthe data model for that (especially the node) was always kind of weird and didn't quite match up to zuul v3... i'm happy for the info to be added back (but modeled better this time).14:36
@jim:acmegating.com(believe it or not -- the actual implementation of that was leftover from zuul v2, so that we knew which jenkins master to direct the stop command to)14:38
@jim:acmegating.com(that's why "node_name" was singular -- only one worker node in jenkins)14:39
@mhuin:matrix.orgah, always wondered why it was the case since zuul supports multi nodes14:39
@mhuin:matrix.orgso I can't really think of a use case where nodes info might be useful in the status json, but the executor info has some value14:40
@fungicide:matrix.orgthere have been times where looking up which nodes were in use for a running job would have been useful (e.g. i spot a job which is starting to fail in a suspicious way and want to ssh into it while the job is still in progress to catch something that an autohold might not), but i agree those are corner cases and with access to executor logs it can already be done14:42
@jim:acmegating.com++ to all of the above14:43
@mhuin:matrix.orgok, thanks for the clarification14:44
@fungicide:matrix.org * there have been times where looking up which nodes were in use for a running build would have been useful (e.g. i spot a build which is starting to fail in a suspicious way and want to ssh into it while the build is still in progress to catch something that an autohold might not), but i agree those are corner cases and with access to executor logs it can already be done14:45
@fungicide:matrix.orgzuul already gives users a dizzying array of information on its web interface, so there's a balance to be struck in order to avoid drowning users in so much information they can't find what they're looking for14:47
@fungicide:matrix.orgbut certainly including it in the api seems reasonable14:48
@mhuin:matrix.orgfungi: yep, the user can be blissfully unaware of what the api's returning14:49
@jim:acmegating.comprobably worth a code comment note with the use case, if we don't actually use it in the web app14:49
@fungicide:matrix.orggreat point, that keeps us from cleaning it up as "unused" later14:49
-@gerrit:opendev.org- James E. Blair https://matrix.to/#/@jim:acmegating.com proposed: [zuul/zuul] 835100: Rely on the unparsed config cache in reconfigurations https://review.opendev.org/c/zuul/zuul/+/83510014:57
@clarkb:matrix.orgcorvus: couple of questions on https://review.opendev.org/c/zuul/zuul/+/83236317:41
-@gerrit:opendev.org- Matthieu Huin https://matrix.to/#/@mhuin:matrix.org proposed: [zuul/zuul-client] 835319: Add dequeue-all subcommand https://review.opendev.org/c/zuul/zuul-client/+/83531920:24
-@gerrit:opendev.org- James E. Blair https://matrix.to/#/@jim:acmegating.com proposed: [zuul/zuul] 832363: Add queue.dependencies-by-topic https://review.opendev.org/c/zuul/zuul/+/83236322:26
@jim:acmegating.comClark: good catch, thanks! :)22:26

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