-@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/+/834857 | 07:01 | |
-@gerrit:opendev.org- Dong Zhang proposed: [zuul/zuul] 834857: Fix bug in getting changed files https://review.opendev.org/c/zuul/zuul/+/834857 | 07: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/+/835074 | 07: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/+/835011 | 07: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/+/835019 | 07:45 | |
-@gerrit:opendev.org- Dong Zhang proposed: [zuul/zuul] 834857: Fix bug in getting changed files https://review.opendev.org/c/zuul/zuul/+/834857 | 09:38 | |
@mhuin:matrix.org | hey 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 anymore | 12:40 |
---|---|---|
@mhuin:matrix.org | is 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/+/830846 | 13:41 | |
@fungicide:matrix.org | mhu: 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/813552 | 14:30 |
@mhuin:matrix.org | fungi, so this is intentional then | 14:30 |
@fungicide:matrix.org | well, i only skimmed the commit messages, but they do call out the removals of those attributes explicitly | 14:31 |
@mhuin:matrix.org | a 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 way | 14:32 |
@mhuin:matrix.org | (we're still running 4.6) | 14:33 |
@mhuin:matrix.org | another 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 executor | 14:34 |
@mhuin:matrix.org | I 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.com | the 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.org | ah, always wondered why it was the case since zuul supports multi nodes | 14:39 |
@mhuin:matrix.org | so 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 value | 14:40 |
@fungicide:matrix.org | there 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 done | 14:42 |
@jim:acmegating.com | ++ to all of the above | 14:43 |
@mhuin:matrix.org | ok, thanks for the clarification | 14: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 done | 14:45 |
@fungicide:matrix.org | zuul 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 for | 14:47 |
@fungicide:matrix.org | but certainly including it in the api seems reasonable | 14:48 |
@mhuin:matrix.org | fungi: yep, the user can be blissfully unaware of what the api's returning | 14:49 |
@jim:acmegating.com | probably worth a code comment note with the use case, if we don't actually use it in the web app | 14:49 |
@fungicide:matrix.org | great point, that keeps us from cleaning it up as "unused" later | 14: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/+/835100 | 14:57 | |
@clarkb:matrix.org | corvus: couple of questions on https://review.opendev.org/c/zuul/zuul/+/832363 | 17: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/+/835319 | 20: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/+/832363 | 22:26 | |
@jim:acmegating.com | Clark: good catch, thanks! :) | 22:26 |
Generated by irclog2html.py 2.17.3 by Marius Gedminas - find it at https://mg.pov.lt/irclog2html/!