| -@gerrit:opendev.org- Zuul merged on behalf of Clark Boylan: [zuul/nodepool] 816389: Fix openshift dep for arm64 docker image builds https://review.opendev.org/c/zuul/nodepool/+/816389 | 00:14 | |
| -@gerrit:opendev.org- Zuul merged on behalf of James E. Blair https://matrix.to/#/@jim:acmegating.com: [zuul/zuul] 816413: Fix change cache relevance detection for refs https://review.opendev.org/c/zuul/zuul/+/816413 | 00:16 | |
| @jim:acmegating.com | Clark, fungi, tobiash, swest, felixedel: hrm, i think i was mistaken about that. i believe the cache cleanup does have an appropriate lock already. i don't know why it deleted in-use changes from the cache. | 00:16 |
|---|---|---|
| @jim:acmegating.com | i think i'm out of ideas other than adding yet more debugging | 00:33 |
| -@gerrit:opendev.org- James E. Blair https://matrix.to/#/@jim:acmegating.com proposed: [zuul/zuul] 816421: Temporarily add debug facilities to connection cache maint https://review.opendev.org/c/zuul/zuul/+/816421 | 01:08 | |
| @jim:acmegating.com | okay, after some more interactive debugging, i think the issue was caused by the cache cleanup happening right after a tenant reconfiguration event. after the reconfig, the queues are empty because all the items are under old_queues. then the pipeline processor runs on that and moves them to the correct queues. to fix this in the short term, i think we should have the general cleanup thread hold the run lock. that should avoid this issue except in the case of a scheduler crash. to make this fully robust, we were already planning on adding a list of changes in a pipeline to zk anywayfor use by isAnyVersionOfChangeInQueue; if we have this method use that, we'll get atomic updates of relevant changes and won't have to worry about tenant reconfigs. | 02:55 |
| -@gerrit:opendev.org- Dong Zhang proposed: [zuul/zuul] 816433: WIP: Check what exception it is https://review.opendev.org/c/zuul/zuul/+/816433 | 05:46 | |
| -@gerrit:opendev.org- Zuul merged on behalf of James E. Blair https://matrix.to/#/@jim:acmegating.com: [zuul/zuul] 816381: Keep consistent types on QueueItem ahead/behind attrs https://review.opendev.org/c/zuul/zuul/+/816381 | 07:04 | |
| -@gerrit:opendev.org- Simon Westphahl proposed: | 07:06 | |
| - [zuul/zuul] 815787: Refresh pipelines in tests when settled https://review.opendev.org/c/zuul/zuul/+/815787 | ||
| - [zuul/zuul] 815788: wip: Allow refreshing project branches https://review.opendev.org/c/zuul/zuul/+/815788 | ||
| - [zuul/zuul] 815278: DNM: execute tests with two schedulers https://review.opendev.org/c/zuul/zuul/+/815278 | ||
| -@gerrit:opendev.org- Simon Westphahl proposed on behalf of James E. Blair https://matrix.to/#/@jim:acmegating.com: [zuul/zuul] 815558: Replace asserts with exceptions https://review.opendev.org/c/zuul/zuul/+/815558 | 07:26 | |
| -@gerrit:opendev.org- Fabien Boucher proposed: [zuul/zuul] 816440: Prevent MR message to be None in order to be process by the scheduler https://review.opendev.org/c/zuul/zuul/+/816440 | 09:04 | |
| @mhuin:matrix.org | 203483 | 09:08 |
| -@gerrit:opendev.org- Zuul merged on behalf of Ian Wienand: [zuul/nodepool] 815766: Dockerfile: install podman from unstable https://review.opendev.org/c/zuul/nodepool/+/815766 | 09:08 | |
| -@gerrit:opendev.org- Felix Edel proposed: | 10:29 | |
| - [zuul/zuul] 814996: Make the ConfigLoader work independently of the Scheduler https://review.opendev.org/c/zuul/zuul/+/814996 | ||
| - [zuul/zuul] 816361: Load system config and tenant layouts in zuul-web https://review.opendev.org/c/zuul/zuul/+/816361 | ||
| - [zuul/zuul] 816362: Implement job freezing API in zuul-web https://review.opendev.org/c/zuul/zuul/+/816362 | ||
| -@gerrit:opendev.org- Simon Westphahl proposed: [zuul/zuul] 816460: Use pipeline change list for cache maintenance https://review.opendev.org/c/zuul/zuul/+/816460 | 11:22 | |
| @westphahl:matrix.org | corvus: ^ took a stab at fixing the cache cleanup. did you have something like this in mind? | 11:23 |
| -@gerrit:opendev.org- Felix Edel proposed: | 13:14 | |
| - [zuul/zuul] 816361: Load system config and tenant layouts in zuul-web https://review.opendev.org/c/zuul/zuul/+/816361 | ||
| - [zuul/zuul] 816362: Implement job freezing API in zuul-web https://review.opendev.org/c/zuul/zuul/+/816362 | ||
| -@gerrit:opendev.org- Matthieu Huin https://matrix.to/#/@mhuin:matrix.org proposed: [zuul/zuul] 816509: zuul-gui: add more documentation about public URL https://review.opendev.org/c/zuul/zuul/+/816509 | 13:39 | |
| @jim:acmegating.com | swest: that's it exactly, thanks! | 14:08 |
| -@gerrit:opendev.org- Felix Edel proposed: [zuul/zuul] 816514: WIP: Implement managenet events directly in zuul-web https://review.opendev.org/c/zuul/zuul/+/816514 | 14:14 | |
| @shrews:matrix.org | corvus: I should be able to define `merge-mode` at the repo level, right? It doesn't need to be at the project config level does it? It doesn't seem to be working as I'd expect for some reason. | 15:17 |
| @clarkb:matrix.org | corvus: can you check my comment on https://review.opendev.org/c/zuul/zuul/+/816460 ? I think the code is functional but wonder if we're doing a bit of excessive type conversions | 15:36 |
| @clarkb:matrix.org | shrews: the docs indicate zuul will use the first merge-mode found for a project. It is possible it is defined multiple times on different branches? | 15:38 |
| @clarkb:matrix.org | shrews: in that way defining it in a project-config repo might make sense as those tend to be loaded first and you can be a bit more deterministic about what value is used (I think that the order in zuul is deterministic anyway but not necessarily in a way that humans would naturally expect) | 15:39 |
| @shrews:matrix.org | Clark: it's defined in multiple branches (wasn't quite sure if that was necessary), but they all have the same value. Not defined at all in project-config for this repo. | 15:40 |
| @shrews:matrix.org | to be clear, trying to get the `squash-merge` mode for our GH repo, but still seeing the separate commits | 15:41 |
| @shrews:matrix.org | Maybe I should just move it to project-config and see if that works | 15:41 |
| @shrews:matrix.org | Was hoping to use the in-repo solution just to have easier control of it | 15:42 |
| @clarkb:matrix.org | I would expect that to work based on my reading of the docs (it would just use the first squash-merge found) | 15:43 |
| -@gerrit:opendev.org- Tobias Henkel proposed: [zuul/zuul] 816528: Pin github3.py to <3.0.0 https://review.opendev.org/c/zuul/zuul/+/816528 | 15:44 | |
| @tobias.henkel:matrix.org | zuul-maint: latest github3.py release breaks zuul with github enterprise < 3.1 ^ | 15:45 |
| @shrews:matrix.org | Clark: yeah, me too | 15:45 |
| @westphahl:matrix.org | Clark: re 816460: are you ok doing this as a follow up? | 16:52 |
| @clarkb:matrix.org | swest: yes I think it is fine to try and clean that up in a followup. This is why I +2'd | 16:55 |
| @clarkb:matrix.org | I was thinking corvus could cross check it and approve if he didn't feel it was important to do in that change. | 16:55 |
| -@gerrit:opendev.org- Simon Westphahl proposed: [zuul/zuul] 816538: Refactor change key/reference resolution https://review.opendev.org/c/zuul/zuul/+/816538 | 17:02 | |
| @westphahl:matrix.org | Clark: ^ something like that? | 17:02 |
| @jim:acmegating.com | Clark, shrews: i agree with what Clark said [was afk] | 17:05 |
| @shrews:matrix.org | corvus: as do I. just weird it doesn't seem to work. going to try the project-config route | 17:06 |
| @clarkb:matrix.org | swest: +2 I think that helps with readability too | 17:08 |
| @jim:acmegating.com | wfm +3 | 17:09 |
| -@gerrit:opendev.org- Zuul merged on behalf of Simon Westphahl: [zuul/zuul] 816460: Use pipeline change list for cache maintenance https://review.opendev.org/c/zuul/zuul/+/816460 | 18:11 | |
| -@gerrit:opendev.org- Zuul merged on behalf of Simon Westphahl: [zuul/zuul] 816538: Refactor change key/reference resolution https://review.opendev.org/c/zuul/zuul/+/816538 | 18:16 | |
| @dmsimard:matrix.org | FYI, upstream EOL of ansible 2.9 and ansible-base 2.10 have been announced: https://groups.google.com/g/ansible-announce/c/kegIH5_okmg/ | 19:03 |
| @jpew:matrix.org | I'm testing out zuul on branch (e.g. not master), and seeing weird behavior; changes from the master branch are "stacking" the gate pipeline. For example, I have changes A B A A A where A is a change from my test branch and B is from master; B doesn't build and disappears as soon as the first A completes gating *but* the later A's won't start building until that B disappears | 19:17 |
| @jpew:matrix.org | This is annoying because if that B wasn't there, the later A's could start building, but instead they wait | 19:18 |
| @jpew:matrix.org | (This is with Gerrit BTW) | 19:18 |
| @jim:acmegating.com | jpew: yep, that's literally the thing zuul was built to do, so it's good that it's doing that. :) it sounds like you might be implicitly saying that your branches A and B are completely independent of each other, and so you want them to have different pipeline change queues? | 19:19 |
| @jpew:matrix.org | Ya; wouldn't each branch need it's own queue? | 19:19 |
| @jim:acmegating.com | jpew: the base assumption in zuul is that branches are not independent; that, for example, openstack wants to test that it can upgrade from one stable branch to the next, so they share a queue. | 19:20 |
| @jim:acmegating.com | jpew: but if, for example, your software has different branches which are completely independent (ie, you never have to upgrade from one to another) there is a setting to change that. | 19:21 |
| @jim:acmegating.com | jpew: see https://zuul-ci.org/docs/zuul/reference/queue_def.html#attr-queue.per-branch | 19:21 |
| @jim:acmegating.com | jpew: my personal advice: think really hard about whether that's true or not :) don't turn it off just because B happens to be broken right now; only do it if a change to B truly never has any possibility to break A. | 19:22 |
| @jpew:matrix.org | corvus: Sure, we definelty do have to upgrade between branches; I don't understand how a single queue fixes that though | 19:23 |
| @jim:acmegating.com | jpew: if you have a job, say it's called the "A-to-B-upgrade-job" and it runs on both branches, then the gate will prohibit merging a change to either branch which breaks that job | 19:24 |
| @jim:acmegating.com | happens a lot around here :) | 19:25 |
| @jpew:matrix.org | Ok, so that explains why it stacks the B changes, but why doesn't it start buidling the A changes speculativly? | 19:25 |
| @jim:acmegating.com | hrm, as soon as B fails, it should shift it out of the way and leave you with A-A-A-A (with a -B tail haging off of that first A). based on your saying that once B is dequeued the remaining AAA changes build, that seems to exclude the possibility that there's a dependency forcing that. so off the top of my head, i don't have an explanation for that. i think your expectation there is correct. | 19:27 |
| @jpew:matrix.org | It's it possibly some weird side effect of B not having any zuul configuration on it? | 19:28 |
| @jim:acmegating.com | oh, no jobs run for B? | 19:29 |
| @jpew:matrix.org | Nothing at all, no jobs, projects, anything | 19:29 |
| @jim:acmegating.com | (i thought when you said it doesn't build, you meant it failed, but you mean there are no jobs...) | 19:29 |
| @jim:acmegating.com | yes, that sounds sufficiently edge-casey that it could be a problem. i think it would be interesting to dig into; but a quick fix might be to just stick a "noop" job on that branch. | 19:30 |
| @jpew:matrix.org | Ok; it's fine for now. Like I said, I'm trying it out on a feature branch. If it's still being weird when we move to master I'll look into it more. | 19:31 |
| @jpew:matrix.org | corvus: In your A-to-B upgrade job, how do you get the artifacts to upgrade from or to? | 19:33 |
| @jim:acmegating.com | jpew: the devstack upgrade job checks out the old branch, installs it, then checks out the new branch and runs the upgrade script. that's a simple source-based approach. | 19:34 |
| @jim:acmegating.com | in a system building artifacts and using provides/requires, you should be able to get those artifacts if you include the branch in the metadata -- you could iterate through zuul.artifacts and get the latest one from that branch. | 19:35 |
| @jpew:matrix.org | Cool. I will keep that in mind. Thanks! | 19:36 |
| -@gerrit:opendev.org- Ian Wienand proposed: [zuul/nodepool] 816555: Bump DIB requirement to 3.15.0 https://review.opendev.org/c/zuul/nodepool/+/816555 | 20:06 | |
| @clarkb:matrix.org | jpew: corvus: OpenDev has an example that uses artifacts to test upgrades between gerrit 3.3 and 3.4 (though everything runs off of one branch) | 20:34 |
| @clarkb:matrix.org | I don't expect it would change much if we ran across multiple branches, only the source of the artifact build would move to branch specific job build | 20:34 |
| -@gerrit:opendev.org- James E. Blair https://matrix.to/#/@jim:acmegating.com proposed: | 20:36 | |
| - [zuul/zuul] 816566: Use CachedBranchConnection in Gerrit driver https://review.opendev.org/c/zuul/zuul/+/816566 | ||
| - [zuul/zuul] 816567: Use CachedBranchConnection in Pagure driver https://review.opendev.org/c/zuul/zuul/+/816567 | ||
| @jim:acmegating.com | Clark, jpew: yeah, there are a lot of similarities between branches and projects wrt this. it's almost fractal. | 20:37 |
| -@gerrit:opendev.org- Matthieu Huin https://matrix.to/#/@mhuin:matrix.org proposed: [zuul/zuul] 734082: web UI: user login with OpenID Connect https://review.opendev.org/c/zuul/zuul/+/734082 | 22:20 | |
| -@gerrit:opendev.org- Matthieu Huin https://matrix.to/#/@mhuin:matrix.org proposed: [zuul/zuul] 734850: web UI: allow a privileged user to dequeue a change https://review.opendev.org/c/zuul/zuul/+/734850 | 22:22 | |
| -@gerrit:opendev.org- Matthieu Huin https://matrix.to/#/@mhuin:matrix.org proposed: [zuul/zuul] 736772: web UI: allow a privileged user to re-enqueue a change https://review.opendev.org/c/zuul/zuul/+/736772 | 22:27 | |
| -@gerrit:opendev.org- Matthieu Huin https://matrix.to/#/@mhuin:matrix.org proposed: [zuul/zuul] 768115: Web UI: allow a privileged user to request autohold https://review.opendev.org/c/zuul/zuul/+/768115 | 22:27 | |
| -@gerrit:opendev.org- Matthieu Huin https://matrix.to/#/@mhuin:matrix.org proposed: [zuul/zuul] 768199: Web UI: add Autoholds, Autohold page https://review.opendev.org/c/zuul/zuul/+/768199 | 22:27 | |
| -@gerrit:opendev.org- Matthieu Huin https://matrix.to/#/@mhuin:matrix.org proposed: [zuul/zuul] 810699: Web UI: Show pipeline types as icons https://review.opendev.org/c/zuul/zuul/+/810699 | 22:28 | |
| -@gerrit:opendev.org- Matthieu Huin https://matrix.to/#/@mhuin:matrix.org proposed: [zuul/zuul] 781858: web UI: allow a privileged user to promote a change https://review.opendev.org/c/zuul/zuul/+/781858 | 22:28 | |
| -@gerrit:opendev.org- Matthieu Huin https://matrix.to/#/@mhuin:matrix.org proposed: [zuul/zuul] 802559: Web UI: Add "Create Autohold Request" form, improve API error messages https://review.opendev.org/c/zuul/zuul/+/802559 | 22:28 | |
| -@gerrit:opendev.org- Matthieu Huin https://matrix.to/#/@mhuin:matrix.org proposed: [zuul/zuul] 769943: Example Docker compose: keycloak integration https://review.opendev.org/c/zuul/zuul/+/769943 | 22:28 | |
| @fungicide:matrix.org | anyone happen to know what might have changed recently to more than halve our znode count in opendev? did zuul simply get much more efficient? https://grafana.opendev.org/d/5Imot6EMk/zuul-status?viewPanel=37&orgId=1&from=now-14d&to=now | 22:43 |
| @jim:acmegating.com | fungi: not specifically off the top of my head; though we merged a lot of bugfixes in .1 through .4 but didn't delete state until this weekend, so maybe we cleaned up something we fixed? | 23:47 |
Generated by irclog2html.py 2.17.2 by Marius Gedminas - find it at https://mg.pov.lt/irclog2html/!