| @michael_kelly_anet:matrix.org | Finally coming back to some actual hacking.. tristanC regarding https://review.opendev.org/c/zuul/zuul-operator/+/853695/10 - this is just a broken way for an operator to function. If I create multiple zuul resources in the same namespace it just won't plain work (or it'll collide in some horrible way) | 04:19 |
|---|---|---|
| @michael_kelly_anet:matrix.org | Also, related to the way the operator functions... using secrets to manage all of the tenants is a bit clumsy - in other examples (eg: strimzi-kafka operator) you'd normally have a seperate resource type for this such as ZuulTenant or something. Any objections if I hack this up? | 04:20 |
| @michael_kelly_anet:matrix.org | Or more specifically, if hacking this up, what's the backwards compatibility store w.r.t to zuul-operator? | 04:26 |
| @michael_kelly_anet:matrix.org | Also, tristanC I was attempting to answer your question on https://review.opendev.org/c/zuul/zuul-operator/+/853585/4 but never got any followup | 04:46 |
| -@gerrit:opendev.org- MICHAEL KELLY proposed: | 04:53 | |
| - [zuul/zuul-operator] 853585: kopf: Upgrade requirement to 1.35.6 https://review.opendev.org/c/zuul/zuul-operator/+/853585 | ||
| - [zuul/zuul-operator] 853586: Only listen for updates to known secrets https://review.opendev.org/c/zuul/zuul-operator/+/853586 | ||
| - [zuul/zuul-operator] 853592: Allow the specification of storageClassName in PVCs https://review.opendev.org/c/zuul/zuul-operator/+/853592 | ||
| - [zuul/zuul-operator] 853695: Prefix zuul-specific resources with instance name https://review.opendev.org/c/zuul/zuul-operator/+/853695 | ||
| - [zuul/zuul-operator] 853696: Prefix nodepool specific resources with instance name https://review.opendev.org/c/zuul/zuul-operator/+/853696 | ||
| - [zuul/zuul-operator] 861279: bug: Select scheduler pod based on instance name on update https://review.opendev.org/c/zuul/zuul-operator/+/861279 | ||
| @q:fricklercloud.de | nodepool seems to have multiple isues when updating static driver configuration. moving a node from one pool to another one doesn't update the node properly. renaming a provider doesn't seem to remove the old provider | 07:35 |
| @newbie2024:matrix.org | Hello, | 13:02 |
| Precisely, what duration is the Zuul Web UI showing in the "duration" field of a finished job? | ||
| I cannot reconcile the "duration" field value | ||
| with the timestamps from job-output.txt. | ||
| E.g. | ||
| Subtracting the first log message "Job console starting..." timestamp from the last log message gives me a larger number. | ||
| I suppose I should skip the first log messages timestamp since the Ansible setup duration is not accounted by the "duration" field, but it would be great to clearly find out how it is calculated. | ||
| I have tried looking at the source code, but did not find an explanation yet. | ||
| @jim:acmegating.com | > <@michael_kelly_anet:matrix.org> Also, related to the way the operator functions... using secrets to manage all of the tenants is a bit clumsy - in other examples (eg: strimzi-kafka operator) you'd normally have a seperate resource type for this such as ZuulTenant or something. Any objections if I hack this up? | 13:25 |
| actually yes. you may not agree with it, but it was an explicit design decision, so i don't recommend hacking on that. here's the background: https://zuul-ci.org/docs/zuul/latest/developer/specs/kubernetes-operator.html#zuul-config | ||
| -@gerrit:opendev.org- Simon Westphahl proposed: [zuul/zuul] 861376: Fix re-use of existing job data when hash matches https://review.opendev.org/c/zuul/zuul/+/861376 | 13:28 | |
| @jim:acmegating.com | newbie2024: i'm surprised you got a larger number. i picked a job at random and got a larger one, which is what i would expect because things happen after the console log is uploaded (though if you watch the log in real time, you'll see more). at any rate, it's when the executor starts and stops running the build. | 13:37 |
| @newbie2024:matrix.org | > <@jim:acmegating.com> newbie2024: i'm surprised you got a larger number. i picked a job at random and got a larger one, which is what i would expect because things happen after the console log is uploaded (though if you watch the log in real time, you'll see more). at any rate, it's when the executor starts and stops running the build. | 13:39 |
| So, you are expecting | ||
| "duration" field value >= (last job-output.txt message timestamp - first job-output.txt message) | ||
| ? | ||
| Also, sorry, I did not mention it, I am using Zuul 3.19.1 | ||
| @jim:acmegating.com | newbie2024: yes, and also, with a version of zuul that old, i don't know if what i wrote applies. (fyi there are multiple security fixes in later versions) | 13:42 |
| @newbie2024:matrix.org | > <@jim:acmegating.com> newbie2024: yes, and also, with a version of zuul that old, i don't know if what i wrote applies. (fyi there are multiple security fixes in later versions) | 13:44 |
| Thanks! I will check that | ||
| -@gerrit:opendev.org- James E. Blair https://matrix.to/#/@jim:acmegating.com proposed: [zuul/nodepool] 858447: Aws: add support for volume iops and throughput https://review.opendev.org/c/zuul/nodepool/+/858447 | 14:08 | |
| @michael_kelly_anet:matrix.org | > <@jim:acmegating.com> actually yes. you may not agree with it, but it was an explicit design decision, so i don't recommend hacking on that. here's the background: https://zuul-ci.org/docs/zuul/latest/developer/specs/kubernetes-operator.html#zuul-config | 14:53 |
| Can you elaborate on this a bit? ConfigMaps are a really generic kind of thing, but make it a bit clumsy to manage. For example, with the existing flow using secrets I need to (1) write a tenant.yaml, (2) base64 encode it in a secret. It makes it really awkward to work with - especially since all tenants are in the same secret | ||
| @michael_kelly_anet:matrix.org | The way these things are injected into secrets or configmaps also just exposes implementation details of zuul (eg: my data for the launcher secret needs to be in nodepool.yaml because that's the file it goes into in production?) that isn't important to know as a user, but makes it more annoying to construct config. | 14:56 |
| @michael_kelly_anet:matrix.org | I used strimzi-kafka as an example because they've done a particularly good job of exposing the salient control primitives in a Kubernetes native way. | 15:04 |
| @michael_kelly_anet:matrix.org | (ie: they have distinct CRDs for kafka, topics, users, kafka connect, etc) | 15:05 |
| @jim:acmegating.com | Michael Kelly: the intent is not to abstract zuul, the intent is to facilitate operation of zuul using zuul's own configuration constructs. zuul already has a way of specifying tenant configuration using yaml; we don't want another way of specifying tenant configuration using yaml that gets converted to the native way of specifying tenant configuration using yaml. basically, it is expected that a human responsible for a zuul system will know how to write a zuul tenant configuration file. | 15:17 |
| @michael_kelly_anet:matrix.org | I understand - this of course makes sense if you already have a deeper knowledge of Zuul. Having recently gone through this process as neither an expert in Zuul, nor in the Zuul operator, I'd suggest this becomes a barrier to entry, but YMMY. :) | 15:22 |
| @jim:acmegating.com | Michael Kelly: i hear you, and that's good feedback. i think i'd characterize our approach as saying that it's worth the investment to learn the zuul part, and that as a project if we tried to do both things at this point we'd be doing each half as well. | 15:27 |
| @michael_kelly_anet:matrix.org | Hopefully I can convince you over time that this is a good approach. ;). I definitely have other short term things to hack on, so NBD. | 15:29 |
| @michael_kelly_anet:matrix.org | Regarding the kopf version I'm using - I'm realizing that this will break with an *earlier* version of kopf. Should I minimum bound this? Or just leave it open entirly? | 15:37 |
| @michael_kelly_anet:matrix.org | * Regarding the kopf version I'm using - I'm realizing that this will break with an _earlier_ version of kopf. Should I minimum bound this? Or just leave it open entirely? | 15:37 |
| @jim:acmegating.com | minimum is fine | 15:37 |
| @michael_kelly_anet:matrix.org | k | 15:38 |
| -@gerrit:opendev.org- MICHAEL KELLY proposed: | 15:40 | |
| - [zuul/zuul-operator] 853585: kopf: Upgrade kopf to at least 1.35.0 https://review.opendev.org/c/zuul/zuul-operator/+/853585 | ||
| - [zuul/zuul-operator] 853586: Only listen for updates to known secrets https://review.opendev.org/c/zuul/zuul-operator/+/853586 | ||
| - [zuul/zuul-operator] 861279: bug: Select scheduler pod based on instance name on update https://review.opendev.org/c/zuul/zuul-operator/+/861279 | ||
| - [zuul/zuul-operator] 853592: Allow the specification of storageClassName in PVCs https://review.opendev.org/c/zuul/zuul-operator/+/853592 | ||
| - [zuul/zuul-operator] 853695: Prefix zuul-specific resources with instance name https://review.opendev.org/c/zuul/zuul-operator/+/853695 | ||
| - [zuul/zuul-operator] 853696: Prefix nodepool specific resources with instance name https://review.opendev.org/c/zuul/zuul-operator/+/853696 | ||
| @michael_kelly_anet:matrix.org | updated the change | 15:40 |
| @michael_kelly_anet:matrix.org | > <@gerrit:opendev.org> MICHAEL KELLY proposed: | 16:54 |
| > - [zuul/zuul-operator] 853585: kopf: Upgrade kopf to at least 1.35.0 https://review.opendev.org/c/zuul/zuul-operator/+/853585 | ||
| > - [zuul/zuul-operator] 853586: Only listen for updates to known secrets https://review.opendev.org/c/zuul/zuul-operator/+/853586 | ||
| > - [zuul/zuul-operator] 861279: bug: Select scheduler pod based on instance name on update https://review.opendev.org/c/zuul/zuul-operator/+/861279 | ||
| > - [zuul/zuul-operator] 853592: Allow the specification of storageClassName in PVCs https://review.opendev.org/c/zuul/zuul-operator/+/853592 | ||
| > - [zuul/zuul-operator] 853695: Prefix zuul-specific resources with instance name https://review.opendev.org/c/zuul/zuul-operator/+/853695 | ||
| > - [zuul/zuul-operator] 853696: Prefix nodepool specific resources with instance name https://review.opendev.org/c/zuul/zuul-operator/+/853696 | ||
| If I could get some reviews on the first 4 items in that stack, that'd be great! | ||
| -@gerrit:opendev.org- Clark Boylan proposed: [zuul/zuul-client] 861477: Update docker images to python 3.10 https://review.opendev.org/c/zuul/zuul-client/+/861477 | 21:43 | |
| -@gerrit:opendev.org- Clark Boylan proposed: [zuul/zuul-operator] 861478: Update the docker images to python 3.10 https://review.opendev.org/c/zuul/zuul-operator/+/861478 | 21:48 | |
| -@gerrit:opendev.org- Clark Boylan proposed: [zuul/zuul-registry] 861479: Update the docker images to python 3.10 https://review.opendev.org/c/zuul/zuul-registry/+/861479 | 21:50 | |
| -@gerrit:opendev.org- Clark Boylan proposed: [zuul/zuul-client] 861477: Update docker images to python 3.10 https://review.opendev.org/c/zuul/zuul-client/+/861477 | 22:23 | |
| -@gerrit:opendev.org- Clark Boylan proposed: [zuul/zuul-registry] 861479: Update the docker images to python 3.10 https://review.opendev.org/c/zuul/zuul-registry/+/861479 | 22:31 | |
| @clarkb:matrix.org | https://zuul.opendev.org/t/zuul/build/909c35984e7a4840a86df3978352a712/log/docker/functional-test_registry_1.txt#376-394 is an interesting failure. It almost looks like docker sent zuul registry invalid json | 22:52 |
Generated by irclog2html.py 2.17.3 by Marius Gedminas - find it at https://mg.pov.lt/irclog2html/!