@clarkb:matrix.org | corvus: question/thought on https://review.opendev.org/c/zuul/zuul/+/830707 too if you have time | 00:25 |
---|---|---|
-@gerrit:opendev.org- James E. Blair https://matrix.to/#/@jim:acmegating.com proposed: [zuul/zuul] 831460: Handle Github branch protection rule webhook events https://review.opendev.org/c/zuul/zuul/+/831460 | 00:37 | |
-@gerrit:opendev.org- Ian Wienand proposed: [zuul/zuul-registry] 831131: [WIP] Enable mitmproxy between docker/podman to dump test https://review.opendev.org/c/zuul/zuul-registry/+/831131 | 00:45 | |
@jim:acmegating.com | Clark: thanks, i agree on both points :) | 00:46 |
@jim:acmegating.com | (but also agree/think that those changes are probably close to their best form for the environment they're in right now) | 00:47 |
@clarkb:matrix.org | Ok. There were some notes on the parent of 830925 as well. But ya nothing worth a -1 | 00:51 |
@jim:acmegating.com | oh missed that! | 00:58 |
@jim:acmegating.com | Clark: ok replied there too, sorry :) | 01:00 |
@clarkb:matrix.org | Thanks! | 01:05 |
-@gerrit:opendev.org- Ian Wienand proposed: [zuul/zuul-registry] 831131: [WIP] Enable mitmproxy between docker/podman to dump test https://review.opendev.org/c/zuul/zuul-registry/+/831131 | 01:58 | |
-@gerrit:opendev.org- Ian Wienand proposed: [zuul/zuul-registry] 831131: [WIP] Enable mitmproxy between docker/podman to dump test https://review.opendev.org/c/zuul/zuul-registry/+/831131 | 02:14 | |
-@gerrit:opendev.org- Ian Wienand proposed: [zuul/zuul-registry] 831131: [WIP] Enable mitmproxy between docker/podman to dump test https://review.opendev.org/c/zuul/zuul-registry/+/831131 | 02:49 | |
-@gerrit:opendev.org- Ian Wienand proposed: [zuul/zuul-registry] 831131: [WIP] Enable mitmproxy between docker/podman to dump test https://review.opendev.org/c/zuul/zuul-registry/+/831131 | 03:45 | |
-@gerrit:opendev.org- Ian Wienand proposed: [zuul/zuul-jobs] 831469: ensure-pip: test with install/upgrade of pip https://review.opendev.org/c/zuul/zuul-jobs/+/831469 | 04:08 | |
-@gerrit:opendev.org- Zuul merged on behalf of Dr. Jens Harbott: [zuul/zuul-jobs] 831443: Fix ensure-pip test on Debian Buster https://review.opendev.org/c/zuul/zuul-jobs/+/831443 | 04:17 | |
-@gerrit:opendev.org- Ian Wienand proposed: [zuul/zuul-registry] 831131: Enable mitmproxy between docker/podman and tesitng image https://review.opendev.org/c/zuul/zuul-registry/+/831131 | 05:24 | |
-@gerrit:opendev.org- Ian Wienand proposed: | 05:46 | |
- [zuul/zuul-registry] 831131: Enable mitmproxy between docker/podman and tesitng image https://review.opendev.org/c/zuul/zuul-registry/+/831131 | ||
- [zuul/zuul-registry] 831480: tox-py38 : don't run on Fedora https://review.opendev.org/c/zuul/zuul-registry/+/831480 | ||
-@gerrit:opendev.org- Zuul merged on behalf of Felix Edel: [zuul/zuul] 830554: Look up worker_zone for log streaming from executor https://review.opendev.org/c/zuul/zuul/+/830554 | 07:14 | |
@iselor:matrix.org | Hi All, | 08:52 |
I've a question regarding Zuul 5.0.1. Is it possible to have moretha | ||
@iselor:matrix.org | * Hi All, | 08:52 |
I've a question regarding Zuul 5.0.1. Is it possible to have more than 1 scheduler instance? | ||
@lidaliu:matrix.org | Yes it is | 09:02 |
@lidaliu:matrix.org | We have 4 today | 09:02 |
-@gerrit:opendev.org- Albin Vass proposed: [zuul/zuul] 831495: Update docs to say large installations can need multiple schedulers https://review.opendev.org/c/zuul/zuul/+/831495 | 09:20 | |
-@gerrit:opendev.org- Szymon Datko proposed: [zuul/zuul-jobs] 831423: [ensure-python] Improve check for CentOS/RHEL 9 packages https://review.opendev.org/c/zuul/zuul-jobs/+/831423 | 13:14 | |
-@gerrit:opendev.org- Szymon Datko proposed: [zuul/zuul-jobs] 831423: [ensure-python] Improve check for CentOS/RHEL 9 packages https://review.opendev.org/c/zuul/zuul-jobs/+/831423 | 13:17 | |
-@gerrit:opendev.org- Szymon Datko marked as active: [zuul/zuul-jobs] 831423: [ensure-python] Improve check for CentOS/RHEL 9 packages https://review.opendev.org/c/zuul/zuul-jobs/+/831423 | 13:17 | |
@fungicide:matrix.org | > <@iselor:matrix.org> Hi All, | 13:53 |
> I've a question regarding Zuul 5.0.1. Is it possible to have more than 1 scheduler instance? | ||
note that 5.0.1 hasn't been released yet, but it's also possible with 5.0.0 (the the recent release). the deployment i help with (zuul.opendev.org) runs two schedulers | ||
@fungicide:matrix.org | https://zuul.opendev.org/components | 13:54 |
@iselor:matrix.org | thanks a lot! | 14:00 |
@iselor:matrix.org | another question, where should I define admin-rules? | 14:01 |
@iselor:matrix.org | do I have to specify admin-rule per gerrit repository? | 14:03 |
@mhuin:matrix.org | admin rules apply at tenant level | 14:03 |
@fungicide:matrix.org | Jakub P.: here's an example: https://opendev.org/openstack/project-config/src/branch/master/zuul/main.yaml#L1-L19 | 14:11 |
@iselor:matrix.org | great! thanks a lot! | 14:11 |
@fungicide:matrix.org | slightly complicated since it uses yaml anchors in order to avoid us needing to duplicate the same set in each tenant | 14:11 |
@fungicide:matrix.org | but should be enough to give you some idea | 14:11 |
@gobi_g:matrix.org | Is there any examples for Prometheus integration? Like what are all the metrics available | 14:39 |
@jim:acmegating.com | karthi: the stats are here: https://zuul-ci.org/docs/zuul/latest/monitoring.html#monitoring you'll need a prometheus statsd exporter | 14:41 |
@avass:vassast.org | karthi: we're using this for example: https://github.com/prometheus/statsd_exporter | 14:42 |
@gobi_g:matrix.org | Thankyou corvus Albin Vass | 14:44 |
@gobi_g:matrix.org | Do we need statsd_exporter for https://zuul-ci.org/docs/zuul/latest/monitoring.html#prometheus-monitoring? | 14:50 |
@gobi_g:matrix.org | * Do we need statsd_exporter for https://zuul-ci.org/docs/zuul/latest/monitoring.html#prometheus-monitoring ? | 14:51 |
@jim:acmegating.com | karthi: no that's native prometheus, but only has a few metrics | 14:51 |
@jim:acmegating.com | you'll probably want to pull both into your prometheus setup to get a complete picture | 14:52 |
@gobi_g:matrix.org | Okay. For native Prometheus port and Prometheus server IP is enough? | 14:53 |
@gobi_g:matrix.org | * Okay. For native option, Prometheus port and Prometheus server IP is enough? | 14:54 |
@gobi_g:matrix.org | * Okay. For native option, adding Prometheus port in scheduler section is enough right? We can configure just need to create Prometheus job. Am I right? | 15:04 |
@gobi_g:matrix.org | * Okay. For native option, adding Prometheus port in scheduler section is enough right? We just need to configure a Prometheus job. Am I right? | 15:04 |
@ekapoun1:matrix.org | Hello, is there a way to allow cyclic dependencies in Zuul? We realized we can end up in a situation where code in two dependent repos have to depend on each other in order to pass their respective checks/gates in order to merge. | 15:08 |
@avass:vassast.org | ekapoun1: yep: https://insightevents.se/vehicle-electronics-connected-services/program-detailed/?utm_campaign=unspecified&utm_content=unspecified&utm_medium=email&utm_source=apsis-anp-3&pe_data=D44405D4B71444651407842465A4371%7C30526000 | 15:09 |
@avass:vassast.org | * ekapoun1: yep: https://www.zuul-ci.org/docs/zuul/latest/config/queue.html#attr-queue.allow-circular-dependencies | 15:09 |
@ekapoun1:matrix.org | > <@avass:vassast.org> ekapoun1: yep: https://www.zuul-ci.org/docs/zuul/latest/config/queue.html#attr-queue.allow-circular-dependencies | 15:11 |
Nice, thanks 👍️ I don't remember seeing that attribute on the queue since before :) Is it new? | ||
@avass:vassast.org | ekapoun1: Can't remember when it was added tbh but I don't think it's super old. | 15:12 |
@gobi_g:matrix.org | > <@gobi_g:matrix.org> Okay. For native option, adding Prometheus port in scheduler section is enough right? We just need to configure a Prometheus job. Am I right? | 15:13 |
Albin Vass: any comments on this? | ||
-@gerrit:opendev.org- Simon Westphahl proposed: [zuul/zuul] 830995: Correctly reset failing cycle behind failing item https://review.opendev.org/c/zuul/zuul/+/830995 | 16:43 | |
-@gerrit:opendev.org- Zuul merged on behalf of Dong Zhang: [zuul/zuul] 814437: In github report, using warning emoji for CANCELED job https://review.opendev.org/c/zuul/zuul/+/814437 | 17:31 | |
-@gerrit:opendev.org- James E. Blair https://matrix.to/#/@jim:acmegating.com proposed: [zuul/zuul] 831107: Add option to show overall duration in buildset table https://review.opendev.org/c/zuul/zuul/+/831107 | 18:59 | |
@tobias.henkel:matrix.org | tristanC, corvus : I see that there are two ansi related stacks that look similar: 831453 and 775726, should we think about rebasing the logfile size threshold onto the new one? | 19:07 |
-@gerrit:opendev.org- James E. Blair https://matrix.to/#/@jim:acmegating.com proposed: [zuul/zuul] 831316: Check if job request is still queued before yielding https://review.opendev.org/c/zuul/zuul/+/831316 | 19:08 | |
@jim:acmegating.com | tobiash: tristanC sgtm; i +2d the old stack | 19:12 |
@jim:acmegating.com | i think we could just merge the old stack instead of 831453? | 19:12 |
@jim:acmegating.com | oh i see it's a little different | 19:13 |
@jim:acmegating.com | i think all 3 of those changes look good... so... whatever it takes :) | 19:14 |
@tobias.henkel:matrix.org | corvus: there is still a -1 on the start of the old stack though | 19:18 |
@tristanc_:matrix.org | ok, i'll do the rebase now | 19:20 |
@jim:acmegating.com | tobiash: thx missed that one. it's +2 now | 19:32 |
@tobias.henkel:matrix.org | corvus: when looking at the overall duration change result (831107) the first thing that came to my mind was that the table is sorted by duration because the drop down sign looks pretty much the same as in other tables the sign that the table is sorted by that column | 19:54 |
@tobias.henkel:matrix.org | I'm not sure if this would confuse some users | 19:54 |
@tobias.henkel:matrix.org | but I also don't have a better idea for that drop down field | 19:54 |
@jim:acmegating.com | tobiash: thanks, that is a really good point and i didn't see that since i wrote the change. i think we could change that to a gear... maybe that would help? | 20:04 |
@tobias.henkel:matrix.org | I think a gear would work | 20:05 |
-@gerrit:opendev.org- Zuul merged on behalf of Tristan Cacqueray: [zuul/zuul] 831450: web: bump re-ansi version https://review.opendev.org/c/zuul/zuul/+/831450 | 20:22 | |
-@gerrit:opendev.org- Zuul merged on behalf of Albin Vass: [zuul/zuul] 831495: Update docs to say large installations can need multiple schedulers https://review.opendev.org/c/zuul/zuul/+/831495 | 20:22 | |
-@gerrit:opendev.org- Tristan Cacqueray proposed: | 20:25 | |
- [zuul/zuul] 775505: web: render links and ansi escape sequences in console https://review.opendev.org/c/zuul/zuul/+/775505 | ||
- [zuul/zuul] 775726: web: disable logfile line rendering when the size exceed a threshold https://review.opendev.org/c/zuul/zuul/+/775726 | ||
- [zuul/zuul] 775510: web: add benchmark test for logfile https://review.opendev.org/c/zuul/zuul/+/775510 | ||
-@gerrit:opendev.org- Tristan Cacqueray proposed: | 20:28 | |
- [zuul/zuul] 775505: web: render links and ansi escape sequences in console https://review.opendev.org/c/zuul/zuul/+/775505 | ||
- [zuul/zuul] 775726: web: disable logfile line rendering when the size exceed a threshold https://review.opendev.org/c/zuul/zuul/+/775726 | ||
- [zuul/zuul] 775510: web: add benchmark test for logfile https://review.opendev.org/c/zuul/zuul/+/775510 | ||
-@gerrit:opendev.org- James E. Blair https://matrix.to/#/@jim:acmegating.com proposed: [zuul/zuul] 831107: Add option to show overall duration in buildset table https://review.opendev.org/c/zuul/zuul/+/831107 | 20:43 | |
@jim:acmegating.com | gear ^ | 20:44 |
-@gerrit:opendev.org- James E. Blair https://matrix.to/#/@jim:acmegating.com proposed: | 20:44 | |
- [zuul/zuul] 831102: Add duration and start time to buildset table https://review.opendev.org/c/zuul/zuul/+/831102 | ||
- [zuul/zuul] 831106: Update patternfly-react https://review.opendev.org/c/zuul/zuul/+/831106 | ||
- [zuul/zuul] 831107: Add option to show overall duration in buildset table https://review.opendev.org/c/zuul/zuul/+/831107 | ||
@jim:acmegating.com | rebase ^ | 20:45 |
@jim:acmegating.com | oh hey, if you want to see one of the new features in action, check out the (expected) merge failure message on https://review.opendev.org/831107 | 20:49 |
@jim:acmegating.com | it now says *which* thing failed | 20:49 |
@jim:acmegating.com | zuul-maint: it would be good if we could get https://review.opendev.org/831240 and https://review.opendev.org/831085 in -- they both fix issues visible in opendev now (neither is critical, but i don't want them to get lost) | 20:59 |
@jim:acmegating.com | i'd like to upgrade opendev again after those merge | 20:59 |
@clarkb:matrix.org | I can review those shortly | 21:01 |
@clarkb:matrix.org | corvus: for https://review.opendev.org/c/zuul/nodepool/+/831240/1/nodepool/zk.py will nodepool write the requests back out without the created time? Does this value need to go in requestor_data to work around that? | 21:08 |
@jim:acmegating.com | Clark: line 526 in toDict should cause it to be written out | 21:09 |
@jim:acmegating.com | Clark: (that's a change to nodepool to do that, btw, in case you missed that's nodepool and not zuul) | 21:10 |
@clarkb:matrix.org | oh yes I did miss that | 21:10 |
-@gerrit:opendev.org- Zuul merged on behalf of James E. Blair https://matrix.to/#/@jim:acmegating.com: [zuul/zuul] 830924: Rename MERGER_FAILURE to MERGE_CONFLICT https://review.opendev.org/c/zuul/zuul/+/830924 | 21:10 | |
@jim:acmegating.com | sticking that in requestor data instead would be a fine option; but it felt like something that should be at the top level. i think the same field does already exist for nodes | 21:11 |
@jim:acmegating.com | (yes, just double checked that, line 588 for nodes) | 21:11 |
@clarkb:matrix.org | ya I'm fine with it top level. I just thought it would get eaten bcause I thought I was looking at the zuul side | 21:12 |
@jim:acmegating.com | you were right :) | 21:12 |
-@gerrit:opendev.org- James E. Blair https://matrix.to/#/@jim:acmegating.com proposed: [zuul/zuul] 831609: Add a tenant reconfiguration metric https://review.opendev.org/c/zuul/zuul/+/831609 | 21:49 | |
-@gerrit:opendev.org- Zuul merged on behalf of James E. Blair https://matrix.to/#/@jim:acmegating.com: [zuul/zuul] 831086: Remove open file limit workaround https://review.opendev.org/c/zuul/zuul/+/831086 | 21:55 | |
-@gerrit:opendev.org- Zuul merged on behalf of James E. Blair https://matrix.to/#/@jim:acmegating.com: [zuul/nodepool] 831240: Retain created_time in node requests https://review.opendev.org/c/zuul/nodepool/+/831240 | 22:08 | |
-@gerrit:opendev.org- Zuul merged on behalf of James E. Blair https://matrix.to/#/@jim:acmegating.com: [zuul/zuul] 830925: Add MERGE_FAILURE buildset result https://review.opendev.org/c/zuul/zuul/+/830925 | 22:37 | |
-@gerrit:opendev.org- James E. Blair https://matrix.to/#/@jim:acmegating.com proposed: [zuul/zuul] 831609: Add a tenant reconfiguration metric https://review.opendev.org/c/zuul/zuul/+/831609 | 22:38 | |
@iwienand:matrix.org | Clark: is it fair to say that the lock/backoff/implementation was basically relying on the parallel uploader not pulling before the upload completed, as so was generically unsafe. this may have been hidden with a combination of zuul-registry wasn't adding the content-lengths and older clients not verifying lengths either? | 23:39 |
@iwienand:matrix.org | the only other possible thing i can think from reading the api is that you could return a 416 to the other client, with a "last-valid-range" *past* the already uploading chunk, which *might* make it upload the next chunk? But I don't think that's right, what if the other upload actually fails, and now you don't have that chunk? -- it does seem that all you can do is accept both uploads and then choose one. | 23:42 |
@iwienand:matrix.org | this is wrt to https://review.opendev.org/c/zuul/zuul-registry/+/831235/3/zuul_registry/storage.py for context | 23:43 |
@clarkb:matrix.org | > <@iwienand:matrix.org> Clark: is it fair to say that the lock/backoff/implementation was basically relying on the parallel uploader not pulling before the upload completed, as so was generically unsafe. this may have been hidden with a combination of zuul-registry wasn't adding the content-lengths and older clients not verifying lengths either? | 23:46 |
Ya I think it's not a pull though it just seems to verify the length immediately after pushing | ||
@clarkb:matrix.org | > <@iwienand:matrix.org> the only other possible thing i can think from reading the api is that you could return a 416 to the other client, with a "last-valid-range" *past* the already uploading chunk, which *might* make it upload the next chunk? But I don't think that's right, what if the other upload actually fails, and now you don't have that chunk? -- it does seem that all you can do is accept both uploads and then choose one. | 23:47 |
Ya letting both uploads complete seemed to be safest and that is what I tried to implement |
Generated by irclog2html.py 2.17.3 by Marius Gedminas - find it at https://mg.pov.lt/irclog2html/!