Wednesday, 2021-11-17

-@gerrit:opendev.org- Zuul merged on behalf of James E. Blair https://matrix.to/#/@jim:acmegating.com: [zuul/zuul] 818116: Fix zuul-web startup config priming https://review.opendev.org/c/zuul/zuul/+/81811601:28
-@gerrit:opendev.org- Zuul merged on behalf of James E. Blair https://matrix.to/#/@jim:acmegating.com: [zuul/zuul] 817869: Add an init phase to scheduler/web startup https://review.opendev.org/c/zuul/zuul/+/81786907:09
-@gerrit:opendev.org- Felix Edel proposed on behalf of Simon Westphahl:08:32
- [zuul/zuul] 815278: DNM: execute tests with two schedulers https://review.opendev.org/c/zuul/zuul/+/815278
- [zuul/zuul] 815787: Refresh pipelines in tests when settled https://review.opendev.org/c/zuul/zuul/+/815787
-@gerrit:opendev.org- Felix Edel proposed:08:32
- [zuul/zuul] 818054: Make TestWeb.test_web_components work with multiple schedulers https://review.opendev.org/c/zuul/zuul/+/818054
- [zuul/zuul] 818203: Execute Github tests with only one scheduler https://review.opendev.org/c/zuul/zuul/+/818203
- [zuul/zuul] 818204: Increase default SQL connection pool size to 10 https://review.opendev.org/c/zuul/zuul/+/818204
- [zuul/zuul] 818205: WIP: Add source attribute to GitConnection https://review.opendev.org/c/zuul/zuul/+/818205
-@gerrit:opendev.org- Simon Westphahl proposed: [zuul/zuul] 818206: Log and ignore exceptions in pipeline processing https://review.opendev.org/c/zuul/zuul/+/81820608:44
-@gerrit:opendev.org- Zuul merged on behalf of Fabien Boucher: [zuul/zuul] 816440: Prevent MR message to be None in order to be process by the scheduler https://review.opendev.org/c/zuul/zuul/+/81644008:54
-@gerrit:opendev.org- Felix Edel proposed on behalf of Simon Westphahl:08:56
- [zuul/zuul] 815278: DNM: execute tests with two schedulers https://review.opendev.org/c/zuul/zuul/+/815278
- [zuul/zuul] 815787: Refresh pipelines in tests when settled https://review.opendev.org/c/zuul/zuul/+/815787
-@gerrit:opendev.org- Felix Edel proposed:08:56
- [zuul/zuul] 818204: Increase default SQL connection pool size to 10 https://review.opendev.org/c/zuul/zuul/+/818204
- [zuul/zuul] 818054: Make TestWeb.test_web_components work with multiple schedulers https://review.opendev.org/c/zuul/zuul/+/818054
- [zuul/zuul] 818203: Execute Github tests with only one scheduler https://review.opendev.org/c/zuul/zuul/+/818203
- [zuul/zuul] 818205: WIP: Add source attribute to GitConnection https://review.opendev.org/c/zuul/zuul/+/818205
-@gerrit:opendev.org- Simon Westphahl proposed: [zuul/zuul] 818213: Load repo state from pipeline state on executors https://review.opendev.org/c/zuul/zuul/+/81821310:38
-@gerrit:opendev.org- Simon Westphahl proposed: [zuul/zuul] 818215: Allow running tests with multiple schedulers https://review.opendev.org/c/zuul/zuul/+/81821510:53
-@gerrit:opendev.org- Felix Edel proposed on behalf of Simon Westphahl:12:27
- [zuul/zuul] 818215: Allow running tests with multiple schedulers https://review.opendev.org/c/zuul/zuul/+/818215
- [zuul/zuul] 815787: Refresh pipelines in tests when settled https://review.opendev.org/c/zuul/zuul/+/815787
- [zuul/zuul] 815278: DNM: execute tests with two schedulers https://review.opendev.org/c/zuul/zuul/+/815278
-@gerrit:opendev.org- Felix Edel proposed:12:27
- [zuul/zuul] 818204: Increase default SQL connection pool size to 10 https://review.opendev.org/c/zuul/zuul/+/818204
- [zuul/zuul] 818054: Make TestWeb.test_web_components work with multiple schedulers https://review.opendev.org/c/zuul/zuul/+/818054
- [zuul/zuul] 818203: Execute Github tests with only one scheduler https://review.opendev.org/c/zuul/zuul/+/818203
- [zuul/zuul] 818205: WIP: Add source attribute to GitConnection https://review.opendev.org/c/zuul/zuul/+/818205
-@gerrit:opendev.org- Simon Westphahl proposed: [zuul/zuul] 818213: Load repo state from pipeline state on executors https://review.opendev.org/c/zuul/zuul/+/81821313:25
@icey:matrix.organy chance that https://opendev.org/zuul/zuul/commit/873028e309b0d0bae65c667e997939302d1be5a5 could actually get released onto the 3.19 branch and have a point release done?13:47
@icey:matrix.orgthere was [discussion at the time](http://lists.zuul-ci.org/pipermail/zuul-discuss/2020-November/001390.html) about doing that but apparently it didn't get done13:50
@tristanc_:matrix.orgicey: note that 3.19 is also affected by https://zuul-ci.org/docs/zuul/reference/releasenotes.html#security-issues13:54
@icey:matrix.orgif 4.0 hadn't made TLS between zoookeeper and the nodes mandatory, I'd be closer to latest :-P That said, it sounds like that's more of a potential risk, depending on the playbooks you're using?13:56
-@gerrit:opendev.org- Zuul merged on behalf of Tristan Cacqueray: [zuul/zuul] 762759: web: integrate re-ansi to render ANSI code in Zuul consoles https://review.opendev.org/c/zuul/zuul/+/76275914:10
-@gerrit:opendev.org- Matthieu Huin https://matrix.to/#/@mhuin:matrix.org proposed on behalf of James E. Blair https://matrix.to/#/@jim:acmegating.com: [zuul/zuul] 817861: Support auth in multiple tabs https://review.opendev.org/c/zuul/zuul/+/81786114:20
-@gerrit:opendev.org- Matthieu Huin https://matrix.to/#/@mhuin:matrix.org proposed:14:20
- [zuul/zuul] 734082: web UI: user login with OpenID Connect https://review.opendev.org/c/zuul/zuul/+/734082
- [zuul/zuul] 734850: web UI: allow a privileged user to dequeue a change https://review.opendev.org/c/zuul/zuul/+/734850
- [zuul/zuul] 736772: web UI: allow a privileged user to re-enqueue a change https://review.opendev.org/c/zuul/zuul/+/736772
- [zuul/zuul] 768115: Web UI: allow a privileged user to request autohold https://review.opendev.org/c/zuul/zuul/+/768115
- [zuul/zuul] 768199: Web UI: add Autoholds, Autohold page https://review.opendev.org/c/zuul/zuul/+/768199
- [zuul/zuul] 810699: Web UI: Show pipeline types as icons https://review.opendev.org/c/zuul/zuul/+/810699
- [zuul/zuul] 781858: web UI: allow a privileged user to promote a change https://review.opendev.org/c/zuul/zuul/+/781858
- [zuul/zuul] 802559: Web UI: Add "Create Autohold Request" form, improve API error messages https://review.opendev.org/c/zuul/zuul/+/802559
- [zuul/zuul] 769943: Example Docker compose: keycloak integration https://review.opendev.org/c/zuul/zuul/+/769943
-@gerrit:opendev.org- Simon Westphahl proposed: [zuul/zuul] 818213: Load repo state from pipeline state on executors https://review.opendev.org/c/zuul/zuul/+/81821314:41
@icey:matrix.orgtristanC: any chance on getting that Python 3.9 fix backported though?14:41
@tristanc_:matrix.orgicey: i dont think the Zuul community is interested in maintaining a 3.19 branch14:45
@jim:acmegating.comi agree, i don't see that happening14:46
-@gerrit:opendev.org- Ade Lee proposed on behalf of Jiri Podivin: [zuul/zuul-jobs] 807031: DNM https://review.opendev.org/c/zuul/zuul-jobs/+/80703114:51
-@gerrit:opendev.org- Felix Edel proposed on behalf of Simon Westphahl: [zuul/zuul] 815278: DNM: execute tests with two schedulers https://review.opendev.org/c/zuul/zuul/+/81527815:05
-@gerrit:opendev.org- Felix Edel proposed:15:05
- [zuul/zuul] 818203: Execute Github tests with only one scheduler https://review.opendev.org/c/zuul/zuul/+/818203
- [zuul/zuul] 818205: WIP: Add source attribute to GitConnection https://review.opendev.org/c/zuul/zuul/+/818205
-@gerrit:opendev.org- Simon Westphahl proposed: [zuul/zuul] 807868: Checkout playbook branch for roles running on tag https://review.opendev.org/c/zuul/zuul/+/80786816:18
-@gerrit:opendev.org- Clark Boylan proposed: [zuul/zuul] 818257: Attempt to errors when updating change dependencies https://review.opendev.org/c/zuul/zuul/+/81825718:25
@clarkb:matrix.orgcorvus:  ^ that is related to https://paste.opendev.org/show/b8QlGAhqB2F9XquiDD1G/ and https://storyboard.openstack.org/#!/story/2009687 I don't have a test yet and have no idea if the code is correct, but wanted to get general shape up as I'm not sure this is the right approach from a high level18:26
@jim:acmegating.comClark: tbh, how important is it that we report an error to the user in that case?  the problem is that the code review system is failing, and that is the mechanism by which we would report the error...18:37
@clarkb:matrix.orgWell I think not reporting anything to the user is an issue when they need to take action to remediate. I agree that we could just hit another failure, but maybe we should try?18:37
@jim:acmegating.comClark: yeah, but this isn't supposed to happen very often...18:38
@jim:acmegating.combasically -- very small chance of the error occurring anyway, and if it does, very high chance the report won't work18:39
@jim:acmegating.comso i guess i'm kind of not sure this is worth putting much effort into, but if you feel like it's worth it i don't object...18:39
@clarkb:matrix.orgYa in this case it was an abrupt network disconnection which seems likely to affect subsequent connections. If it was say an http 500 error or similar maybe trying to report would be worthwhile since it is different enough to the server it might actually work18:40
@clarkb:matrix.orgI'll have to think about it more. The other thought I had was to implement retries18:41
@clarkb:matrix.orgmaybe it would be better to retry in a short window of time and try to get past the issue instead18:41
@jim:acmegating.commaybe so18:41
@jim:acmegating.comregarding your TODO question... tbh i'm not sure of the answer; enqueing it without changes ahead could be risky.  i think you'd have to consider what happens if the scheduler crashes at any point there -- is the pipeline in a state where the next scheduler will be able to know that it needs to be dequeued, or will it thisk it's supposed to be there and start running jobs in an invalid configuration.  i think unit testing that is going to be important.18:43
@clarkb:matrix.orgya, we do that for cycles below18:44
@clarkb:matrix.orgI guess the question extends to that code too18:44
@clarkb:matrix.orgthe more I'm thinking about this the more I think retries would be better because if we cannot connect we cannot report. But if we retry the underlying requests we have the chance to actually perform the requested job work18:45
@jim:acmegating.com++18:45
@clarkb:matrix.orgI'm glad I pushed early for feedback :)18:49
-@gerrit:opendev.org- Clark Boylan proposed: [zuul/zuul] 818257: Retry dependency update requests https://review.opendev.org/c/zuul/zuul/+/81825719:04
@jim:acmegating.comClark: if you have a sec, i just +2d 3 #sos changes19:04
@clarkb:matrix.orgcorvus: yup now that ^ is updated I can take a look19:05
@jim:acmegating.com+2 with comment19:09
@clarkb:matrix.orgcorvus: responded with a question for clarification if you have a moment19:13
@clarkb:matrix.orgtobiash: corvus:  for https://review.opendev.org/c/zuul/zuul/+/818147/1/zuul/manager/__init__.py it isn't possible that we will call addChange twice because only one scheduler is processing events at a time right? and once the event is removed from the queue we either process it in that scheduler or we don't process it at all?19:14
@clarkb:matrix.orgAlso I think changes like https://review.opendev.org/c/zuul/zuul/+/818213 are what we need to be careful of once we release v5?19:21
@clarkb:matrix.orgI think those requests are ephemeral which means we won't need to do a full clear of the db but we will have to do an offline restart?19:21
@clarkb:matrix.orgI've approved it. I don't think this is an issue until we do a release where people have the expectation of rolling restarts19:22
@clarkb:matrix.orgI'm good to approve 818147 if my question and self answer make sense to someone other than myself :)19:24
@jim:acmegating.comClark: replied19:54
-@gerrit:opendev.org- Tristan Cacqueray proposed on behalf of Joshua Hesketh: [zuul/zuul] 607079: Separate out executor server from runner https://review.opendev.org/c/zuul/zuul/+/60707920:40
@tristanc_:matrix.orgcorvus: it's quite tricky to rebase that old 607079 change, if I can make it pass the test again, could we please fast track its review?20:44
@jim:acmegating.comtristanC: unfortunately, i'm not in a position to review it right now20:50
-@gerrit:opendev.org- Zuul merged on behalf of Ian Wienand: [zuul/nodepool] 818141: Bump DIB to 3.15.2 https://review.opendev.org/c/zuul/nodepool/+/81814120:52
@tristanc_:matrix.orgThat's fine, I guess this will have to wait after zuul v5. Or perhaps the zuul-runner is no longer something we want to support and we should remove the spec?20:55
@jim:acmegating.comtristanC: it's probably worth a check in to see if folks still want it -- it's certainly complex, and only worth doing if it will get some real use.  regardless of that, it does seem like post-5.0 would be a better time anyway :)20:59
@jim:acmegating.comzuul-maint: fyi i'll be afk from tomorrow through sunday21:01
@tristanc_:matrix.orgThere is definitely a need for it, there is a whole project dedicated to setup a complete zuul just to re-run a single job. And a lighter solution is being developed in https://github.com/bregman-arie/ci-runner21:01
@tristanc_:matrix.orgBut I think that that implementing zuul-runner may not be the right solution to enable running a zuul jobs locally. Afterall, zuul jobs are composed of Ansible tasks, and perhaps we can figure out a process to run those tasks with Ansible directly...21:04
@jim:acmegating.comyou know me, i'm always in favor of just running the job playbook :)21:06
@tristanc_:matrix.orgThus I feel like zuul-runner is sending the wrong signal, and I wonder what can be done to reduce the job dependencies on the Zuul runtime.21:07
@clarkb:matrix.orgI personally prefer when repos don't tie too closely to the CI system that running the CI system related tools are necessary to run things locally. I'm a big fan of make/tox/bazel/etc for that sort of thing21:08
@jim:acmegating.com++21:12
@tristanc_:matrix.orgClark: right, and i think that is precisely the issue of the playbooks and roles created for zuul jobs. Without zuul, you have to figure out the external role location, and what is the expected state of the system (for example to copy the project sources and setup multinode)21:13
@clarkb:matrix.org> <@tristanc_:matrix.org> Clark: right, and i think that is precisely the issue of the playbooks and roles created for zuul jobs. Without zuul, you have to figure out the external role location, and what is the expected state of the system (for example to copy the project sources and setup multinode)21:17
Right and I'm saying that for 80% of the problems its sufficient to use a tool like make or tox. Then for the more convoluted setups you're not going to easily replicate those locally in many cases anyway so relying on the CI system is probably going to happy. Its not perfect, btu I think in cases like figuring out multinode testing relying on the actual multinode CI jobs for that makes a lot of sense
@jim:acmegating.comleaning more heavily on autoholds may help there21:18
@clarkb:matrix.orgTaking multinode as an example we had a cloud (just one) dropping GRE tunnel packets. Debugging that locally would have been impossible :/ Once the complexity of the job reaches that level you really do want to interact with the job as it runs in reality. Thats not to say it shouldn't be easier, it just isn't a priority for me as I'll push to tox for simpler stuff and then ya do holds for when it gets complex21:22
@tristanc_:matrix.orgWell i wonder if it has to be that way, and it seems like enabling users to re-use the zuul-jobs manually would be very valuable.21:24
@tristanc_:matrix.orgI'm not sure what is the plan for the collections, but perhaps the zuul job web interface could provide a requirements.yml file and the instructions to run the content?21:29
@jim:acmegating.comgtema: i don't think your squash change is complete: https://opendev.org/zuul/zuul/src/branch/master/zuul/driver/gitlab/gitlabconnection.py#L433-L434  params appears unused.  if you fix that, it would be good to add a test.21:43
-@gerrit:opendev.org- Tristan Cacqueray proposed on behalf of Joshua Hesketh: [zuul/zuul] 607079: Separate out executor server from runner https://review.opendev.org/c/zuul/zuul/+/60707921:46
-@gerrit:opendev.org- Matthieu Huin https://matrix.to/#/@mhuin:matrix.org proposed:21:52
- [zuul/zuul] 769943: Example Docker compose: keycloak integration https://review.opendev.org/c/zuul/zuul/+/769943
- [zuul/zuul] 818295: web UI: Add a credentials renew modal https://review.opendev.org/c/zuul/zuul/+/818295
-@gerrit:opendev.org- Zuul merged on behalf of Simon Westphahl: [zuul/zuul] 818213: Load repo state from pipeline state on executors https://review.opendev.org/c/zuul/zuul/+/81821322:01
-@gerrit:opendev.org- Zuul merged on behalf of Tobias Henkel: [zuul/zuul] 818147: Remove reported_enqueue flag from queue item https://review.opendev.org/c/zuul/zuul/+/81814722:01
-@gerrit:opendev.org- Matthieu Huin https://matrix.to/#/@mhuin:matrix.org proposed:22:02
- [zuul/zuul] 818295: web UI: Add a credentials renew modal https://review.opendev.org/c/zuul/zuul/+/818295
- [zuul/zuul] 769943: Example Docker compose: keycloak integration https://review.opendev.org/c/zuul/zuul/+/769943
@spamaps:spamaps.ems.hosttristanC: FYI, the openshift-pods driver has gotten me much farther, thank you. :) I may need to add some things to it as we have some metadata that we need to set to satisfy our admission controllers and I don't see any way to do that.22:21
@tristanc_:matrix.orgspamaps: that's good to hear, thanks for the feedback. I guess we could replicate this setting https://zuul-ci.org/docs/nodepool/aws.html#attr-providers.[aws].pools.labels to set custom metadata22:28
@tristanc_:matrix.org * spamaps: that's good to hear, thanks for the feedback. I guess we could replicate this setting https://zuul-ci.org/docs/nodepool/aws.html#attr-providers.[aws].pools.labels.tags to set custom metadata22:29
-@gerrit:opendev.org- James E. Blair https://matrix.to/#/@jim:acmegating.com proposed: [zuul/zuul] 818300: Add support for adding and removing labels in gitlab https://review.opendev.org/c/zuul/zuul/+/81830023:40
@jim:acmegating.comthat got me thinking maybe we should consider treating gerrit hashtags like we do labels in github/gitlab23:40

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