| -@gerrit:opendev.org- Zuul merged on behalf of James E. Blair https://matrix.to/#/@jim:acmegating.com: [zuul/zuul] 944159: Remove unused provider methods https://review.opendev.org/c/zuul/zuul/+/944159 | 00:22 | |
| -@gerrit:opendev.org- Clark Boylan proposed on behalf of Joseph Kostreva: [zuul/zuul] 933138: Add zuul regex support to project definitions https://review.opendev.org/c/zuul/zuul/+/933138 | 01:21 | |
| @joao15130:matrix.org | Hi guys, is there a way to tell Zuul to recreate an authohold request once the previous one is deleted? Or in other words is there any way to release a nodepool instance without the need to delete the autohold request? | 06:41 |
|---|---|---|
| @flaper87:matrix.org | In our case, we do because it's a configmap in k8s. So, we update that one and restart the pod. | 08:07 |
| @flaper87:matrix.org | Interesting! Do you have more context on why this was done? Curious to learn more :) | 08:07 |
| @flaper87:matrix.org | I will answer my own question with a link to the commit: https://opendev.org/zuul/zuul/commit/8dab278845c97a55c0047b0f5d93d1d25f929278 | 08:13 |
| @flaper87:matrix.org | that makes sense, thanks | 08:13 |
| @dpawlik:matrix.org | Clark: do you think that if I increase "rate" from 1.0 to 5 would help? | 09:20 |
| @tristanc_:matrix.org | dpawlik: it's unlikely to affect the provider "responsiveness" because the rate should be handled by the individual request handler, not the main PoolWorker. It looks like we need something else to accommodate the latency of remote launchers, or change the scheduling logic to ensure more fairness. | 11:28 |
| @tristanc_:matrix.org | Clark: do you think it would be reasonable to periodically measure the PoolWorker latency (e.g. using ping request), and give enough time for every launcher to accept a request before selecting and running the handler? | 11:49 |
| @fungicide:matrix.org | tristanc_: a launcher's responsiveness doesn't necessarily rely on network round-trip time, there are many more factors which could influence it. if you really wanted to be sure every launcher got a turn, you'd need something akin to a token ring | 13:21 |
| -@gerrit:opendev.org- Felix Edel proposed: [zuul/zuul] 945104: Fix promote event handling for github changes https://review.opendev.org/c/zuul/zuul/+/945104 | 13:23 | |
| -@gerrit:opendev.org- Felix Edel proposed: [zuul/zuul] 945104: Fix promote event handling for github changes https://review.opendev.org/c/zuul/zuul/+/945104 | 13:25 | |
| -@gerrit:opendev.org- Felix Edel proposed: [zuul/zuul] 945104: Fix promote event handling for github changes https://review.opendev.org/c/zuul/zuul/+/945104 | 14:02 | |
| @clarkb:matrix.org | tristanC: fungi: is right you could have the lowest point but longest boot process. You really need a measure of noderequest throughput and then coordination around that. I'm not even sure I understand what you would measure the ping between? | 14:29 |
| @clarkb:matrix.org | Increasing the rate on fast providers would in theory slow them down some perhaps enough to allow slow providers to have a turn | 14:29 |
| @clarkb:matrix.org | * @tristanc_:matrix.org: @fungicide:matrix.org: is right you could have the lowest ping but longest boot process. You really need a measure of noderequest throughput and then coordination around that. I'm not even sure I understand what you would measure the ping between? | 14:30 |
| @tristanc_:matrix.org | Clark: I'm also not sure how to fix that, it's just that presently we have nodepool-launchers far from our control plane, and their providers are almost never used because the local launcher accept the request too fast. | 14:34 |
| @tristanc_:matrix.org | * Clark: I'm also not sure how to fix that, it's just that presently we have nodepool-launchers far from our control plane, and their providers are almost never used because the local launcher accepts the requests too fast. | 14:34 |
| @jim:acmegating.com | flaper87: see https://gerrit.googlesource.com/zuul/ops/+/refs/heads/master/playbooks/deploy.yaml for an idea of how to fix that | 14:36 |
| @jim:acmegating.com | tristanC: i expect nodepool in zuul to address that, at least to some extent. so i wouldn't recommend over-engineering something now. | 14:37 |
| @tristanc_:matrix.org | corvus: I agree, for now we are using dedicated label to spread our workload, and we are looking forward using nodepool in zuul too! | 14:40 |
| @clarkb:matrix.org | https://unix.stackexchange.com/questions/669232/how-to-throttle-bandwidth-of-ssh-connection something like this between the fast launcher and zookeeper? | 14:42 |
| @clarkb:matrix.org | That's a total hack but should have the desired effect | 14:42 |
| @flaper87:matrix.org | Thanks! Ya, need to implement something similar. Tricky thing is that zuul-scheduler needs to be running. I was hoping to put this inside an initContainer but that would require to run scheduler, wait for it, run smart-reconfigure, etc. At that point, it may be easier to just run a sidecar container or a job that calls smart-reconfigure | 14:47 |
| -@gerrit:opendev.org- Tony Breeds proposed: [zuul/nodepool] 944118: Add Non-voting noble job https://review.opendev.org/c/zuul/nodepool/+/944118 | 16:39 | |
| -@gerrit:opendev.org- Tony Breeds proposed: [zuul/nodepool] 944118: Add Non-voting noble job https://review.opendev.org/c/zuul/nodepool/+/944118 | 17:07 | |
| @ratmice:matrix.org | Hi, I was curious if people had experience using zuul with rust and cross repository changes. In the sense that I could imagine it would require a custom cargo package registry to distribute the modified package when one change proposes a version bump. So, I'm curious if this is something people have experience with? | 18:05 |
| @fungicide:matrix.org | ratmice: i don't know much about rust, but if cargo can't install from git repositories, then yeah probably something similar to how we do speculative container references with buildset and intermediate registries could be a solution | 18:07 |
| @mnaser:matrix.org | Hi ratmice ! we use zuul with rust and nice to see people exploring it. | 18:07 |
| I was actually thinking of working on something for this if people have interest, specifically I think the easiest way for this is to leverage the patch function of cargo to point to the locally checked out repo by Zuul! | ||
| @mnaser:matrix.org | https://doc.rust-lang.org/cargo/reference/overriding-dependencies.html#the-patch-section | 18:08 |
| @mnaser:matrix.org | It would just be a matter of checking the required projects, matching crate names and updating the cargo.toml prior to starting whatever you need to do. | 18:08 |
| @ratmice:matrix.org | Oh yeah, I could definitely see how that might work and be less involved | 18:09 |
| @mnaser:matrix.org | So Zuul takes care of checking out all the repos on disk and we would just need to massage the cargo file really | 18:09 |
| @clarkb:matrix.org | https://doc.rust-lang.org/cargo/reference/specifying-dependencies.html#specifying-dependencies-from-git-repositories https://doc.rust-lang.org/cargo/reference/specifying-dependencies.html#specifying-path-dependencies and https://doc.rust-lang.org/cargo/reference/specifying-dependencies.html#multiple-locations seem relevant | 18:10 |
| @fungicide:matrix.org | oh, in that case could something similar to the python siblings handler work? | 18:10 |
| @clarkb:matrix.org | looks like you might be able to specify a dependency either from git or as a local path. Then set multiple dependencies with some perference hierarchy? | 18:10 |
| @fungicide:matrix.org | basically auto-delect from the required-projects list and then hack the manifest on the fly to replace crate references with the direct git repo paths in the workspace | 18:11 |
| @clarkb:matrix.org | I'm not sure if multiple dependency locations is better or worse toe dynamic but explicit patch sections | 18:12 |
| @mnaser:matrix.org | > <@fungicide:matrix.org> basically auto-delect from the required-projects list and then hack the manifest on the fly to replace crate references with the direct git repo paths in the workspace | 18:12 |
| yup! pretty much the same exact playbook :) | ||
| @clarkb:matrix.org | but it does seem cargo has enough flexibility to make something work | 18:12 |
| @fungicide:matrix.org | agreed, the sorts of hoops we jump through for speculative container builds would almost certainly be overkill for this | 18:13 |
| @fungicide:matrix.org | seems like the rust ecosystem is not nearly as pathological as the docker ecosystem | 18:14 |
| @clarkb:matrix.org | * I'm not sure if multiple dependency locations is better or worse compared to dynamic but explicit patch sections | 18:14 |
| @mnaser:matrix.org | I think it’s possible someone just needs the time to work on that for sure | 18:17 |
| @ratmice:matrix.org | Well, i'll definitely give it a go if I can get the others to agree on trying out zuul, but it is at this point just something I imagine could help. But if I do get further I'll definitely spend some time on it. | 18:24 |
| @mnaser:matrix.org | I’m more than willing to help review and get that through if you wind up walking that path :) you can consider it done. We also have already a bunch of base jobs we can push up for cargo base/clippy/etc | 18:25 |
| -@gerrit:opendev.org- Zuul merged on behalf of James E. Blair https://matrix.to/#/@jim:acmegating.com: [zuul/zuul] 944160: AWS: add security-group-id support https://review.opendev.org/c/zuul/zuul/+/944160 | 18:29 | |
| @clarkb:matrix.org | Aurelio Jargas: I have reviewed that ensure-python-command role change. I have a few questions/thoughts but nothing unexpected | 18:40 |
| @clarkb:matrix.org | Aurelio Jargas: let me know if you have questions with what I posted to the change | 18:40 |
| @clarkb:matrix.org | Aurelio Jargas: I also just had a thought that you could push changes to say zuul/zuul that depends on https://review.opendev.org/c/zuul/zuul-jobs/+/941490 in order to see zuul's use of nox run through the new ensure-nox role | 18:53 |
| @clarkb:matrix.org | I don't know that that is super necessary as we do have testing of things otherwise I think. But might be a nice double check with real world jobs | 18:53 |
| -@gerrit:opendev.org- Zuul merged on behalf of Simon Westphahl: [zuul/zuul] 944967: Run a deduplicated job if it matches any change https://review.opendev.org/c/zuul/zuul/+/944967 | 19:08 | |
| @ratmice:matrix.org | FWIW, since I didn't really explain how what I was thinking about doing with cargo would work, and why I think it has some benefits | 20:08 |
| @ratmice:matrix.org | Cargo has a thing called [registries](https://doc.rust-lang.org/cargo/reference/registries.html) you can change the default from crates.io to your own registry via [.cargo/config.toml](https://doc.rust-lang.org/cargo/reference/config.html) | 20:09 |
| @ratmice:matrix.org | The nice thing is you don't have to mirror cargo's dependency resolution (where you can depend upon multiple versions of a crate), or modify the Cargo.toml at all | 20:10 |
| @ratmice:matrix.org | I think you'd just need to recognize that a version number was bumped, and make that release available on a local registry, otherwise that falls back to crates.io registry | 20:11 |
| @ratmice:matrix.org | It *might* be a bit more involved than trying to modify Cargo.toml but I think it might avoid some hairy problems | 20:12 |
| @ratmice:matrix.org | Anyhow, they are probably both approaches worth investigating | 20:13 |
| @clarkb:matrix.org | ratmice: we use a similar approach with container image registries. But in those cases we're largely forced into it due to lack of alternatives | 20:14 |
| @jim:acmegating.com | yeah, both are likely possible; patch and cargo.toml are likely to be lightweight solutions, an external registry is more involved. but we have examples of both patterns with zuul. | 20:19 |
| @fungicide:matrix.org | the good, the bad, and the ugly | 20:28 |
| -@gerrit:opendev.org- Zuul merged on behalf of James E. Blair https://matrix.to/#/@jim:acmegating.com: [zuul/zuul] 944161: AWS: Add imdsv2 support https://review.opendev.org/c/zuul/zuul/+/944161 | 22:16 | |
| -@gerrit:opendev.org- Clark Boylan proposed on behalf of Joseph Kostreva: [zuul/zuul] 933138: Add zuul regex support to project definitions https://review.opendev.org/c/zuul/zuul/+/933138 | 23:21 | |
| -@gerrit:opendev.org- Ruisi Jian proposed: [zuul/zuul] 945175: WIP: fix file comment line mapping https://review.opendev.org/c/zuul/zuul/+/945175 | 23:50 | |
Generated by irclog2html.py 2.17.3 by Marius Gedminas - find it at https://mg.pov.lt/irclog2html/!