| -@gerrit:opendev.org- Zuul merged on behalf of James E. Blair https://matrix.to/#/@jim:acmegating.com: [zuul/zuul] 937475: Add ability to mark individual job attributes as final https://review.opendev.org/c/zuul/zuul/+/937475 | 03:28 | |
| -@gerrit:opendev.org- Zuul merged on behalf of Simon Westphahl: [zuul/zuul] 941096: Remove deep copying of config https://review.opendev.org/c/zuul/zuul/+/941096 | 04:37 | |
| -@gerrit:opendev.org- Zuul merged on behalf of Jeremy Stanley https://matrix.to/#/@fungicide:matrix.org: [zuul/nodepool] 942945: Pin grpcio and revert googleapis-common-protos pin https://review.opendev.org/c/zuul/nodepool/+/942945 | 05:01 | |
| -@gerrit:opendev.org- Zuul merged on behalf of James E. Blair https://matrix.to/#/@jim:acmegating.com: [zuul/nodepool] 942939: Clear allocation when unlocking failed node requests https://review.opendev.org/c/zuul/nodepool/+/942939 | 05:11 | |
| -@gerrit:opendev.org- Zuul merged on behalf of James E. Blair https://matrix.to/#/@jim:acmegating.com: [zuul/zuul] 942407: Add quota support to zuul-launcher https://review.opendev.org/c/zuul/zuul/+/942407 | 05:36 | |
| -@gerrit:opendev.org- Zuul merged on behalf of James E. Blair https://matrix.to/#/@jim:acmegating.com: [zuul/zuul] 942738: Store failed provider node data on request https://review.opendev.org/c/zuul/zuul/+/942738 | 06:00 | |
| -@gerrit:opendev.org- Dong Zhang proposed: [zuul/zuul] 940872: Implement keystore functions for OIDC RS256 https://review.opendev.org/c/zuul/zuul/+/940872 | 14:16 | |
| -@gerrit:opendev.org- Dong Zhang proposed: [zuul/zuul] 940971: Manage OIDC signing key rotation https://review.opendev.org/c/zuul/zuul/+/940971 | 14:38 | |
| -@gerrit:opendev.org- Dong Zhang proposed: [zuul/zuul] 942432: Implement zuul-web OIDC endpoints https://review.opendev.org/c/zuul/zuul/+/942432 | 14:39 | |
| -@gerrit:opendev.org- Dong Zhang proposed: [zuul/zuul] 942886: Prepare oidc token for playbook execution in executor. https://review.opendev.org/c/zuul/zuul/+/942886 | 14:40 | |
| -@gerrit:opendev.org- Dong Zhang proposed: [zuul/zuul] 941235: Implement command for deleting OIDC signing keys https://review.opendev.org/c/zuul/zuul/+/941235 | 14:41 | |
| -@gerrit:opendev.org- Dong Zhang proposed: [zuul/zuul] 941629: Use ZuulTreeCache for OIDC signing keys https://review.opendev.org/c/zuul/zuul/+/941629 | 14:42 | |
| -@gerrit:opendev.org- James E. Blair https://matrix.to/#/@jim:acmegating.com proposed: [zuul/zuul] 943016: Add centos9/10 to quickstart https://review.opendev.org/c/zuul/zuul/+/943016 | 15:24 | |
| -@gerrit:opendev.org- James E. Blair https://matrix.to/#/@jim:acmegating.com proposed: [zuul/zuul] 943021: Pin confluent-kafka https://review.opendev.org/c/zuul/zuul/+/943021 | 15:49 | |
| -@gerrit:opendev.org- James E. Blair https://matrix.to/#/@jim:acmegating.com proposed: [zuul/zuul] 943022: Add librdkafka-dev to bindep https://review.opendev.org/c/zuul/zuul/+/943022 | 15:52 | |
| @jim:acmegating.com | zuul-maint: ^ a quick review of 021 and 022 would be appreciated since that's blocking everything, and there are a few more things id like to get merged before the opendev restart | 15:53 |
|---|---|---|
| @jim:acmegating.com | https://pypi.org/project/confluent-kafka/#history fyi | 15:55 |
| @clarkb:matrix.org | corvus: can you check my question on the second change? | 16:08 |
| @jim:acmegating.com | heh yep | 16:08 |
| -@gerrit:opendev.org- James E. Blair https://matrix.to/#/@jim:acmegating.com proposed: [zuul/zuul] 943022: Add librdkafka-dev to bindep https://review.opendev.org/c/zuul/zuul/+/943022 | 16:09 | |
| -@gerrit:opendev.org- James E. Blair https://matrix.to/#/@jim:acmegating.com proposed: [zuul/zuul] 943022: Add librdkafka-dev to bindep https://review.opendev.org/c/zuul/zuul/+/943022 | 16:09 | |
| @clarkb:matrix.org | corvus: I acutally had one last thought I just posted. Sorry it didn't occur to me until after the other bindep comment | 16:10 |
| @clarkb:matrix.org | I'm not sure if that is necessary it likely depends on whether or not the wheel bundles up all the library stuff it needs from where it was built or if it expects the system to host that library for it | 16:10 |
| @jim:acmegating.com | yeah that's unclear. their install instructions don't say anything about that; so perhaps the only change is "who builds the wheel". | 16:12 |
| @jim:acmegating.com | https://github.com/confluentinc/confluent-kafka-python/issues/1927 | 16:13 |
| @jim:acmegating.com | that's the confused users thread. maybe an answer will show up there. but if the only issue is "they didn't build the wheel" then probably 022 should be good as-is. | 16:13 |
| @jim:acmegating.com | we can probably wait a bit for clarification; i don't think there's a rush to merge 022. just wanted to not forget. | 16:14 |
| @clarkb:matrix.org | looking at the pypi page for the pacakge it looks like the published wheels (2.8.0 and earlier) don't support some features and if you want those you need all the library stuff in place and build your own wheel. So I wonder if this is a more complicated case of "yes but" | 16:15 |
| @clarkb:matrix.org | agreed the first change should be sufficient to get things working while we wait for clarification | 16:15 |
| @dfajfer:fsfe.org | can you somehow tell Zuul during merge to use zuul.yaml from incoming branch instead of current branch? | 16:15 |
| @dfajfer:fsfe.org | this is in a merge | 16:15 |
| @clarkb:matrix.org | you mean you are testing a merge commit? I would expect zuul to use the config that results from that merge not one side or the other | 16:17 |
| @dfajfer:fsfe.org | yeah that would work, however for my setup it keeps using zuul.yaml from the first parent | 16:19 |
| @dfajfer:fsfe.org | * yeah that would work, however for my setup it keeps using zuul.yaml from the second parent (2way merge) | 16:19 |
| @clarkb:matrix.org | is this in a trusted config repo? That wouldn't use speculative state so would use what has already merged (which would be the first parent?) | 16:20 |
| @dfajfer:fsfe.org | nope, sorry didn't clarify but it's not a trusted repo | 16:20 |
| @dfajfer:fsfe.org | this is Gerrit if this is relevant | 16:20 |
| @dfajfer:fsfe.org | * nope, sorry didn't clarify but it's not a untrusted repo | 16:21 |
| @dfajfer:fsfe.org | * nope, sorry didn't clarify but it's an untrusted repo | 16:21 |
| @clarkb:matrix.org | that is unexpected to me. I would expect the zuul mergers to build out a state that applies the merge commit then uses the zuul config from there. Maybe the mergers aren't merging things cleanly? | 16:24 |
| @dfajfer:fsfe.org | I thought this is standard behaviour for Zuul, however it's annoying in one tenant and I wanted to fix it | 16:24 |
| @dfajfer:fsfe.org | this is how it works for us globally:p | 16:25 |
| @clarkb:matrix.org | are you using the default merge strategy for gerrit? | 16:31 |
| @clarkb:matrix.org | looks like corvus added merge ops details to workspace-repos.json files | 16:34 |
| @clarkb:matrix.org | specifically to record merge operations and reproduce them later. That info might be useful in further debugging | 16:34 |
| @dfajfer:fsfe.org | fast-forward only | 16:35 |
| @clarkb:matrix.org | looking at that workspace-repos.json file in our jobs it records each git command used to merge things in order. I would look at that file and check that the results are what you expect | 16:36 |
| @clarkb:matrix.org | (by actually performing the merges and checking the result) | 16:36 |
| @dfajfer:fsfe.org | my zuul is too old it seems, the json was added 11mnths ago | 16:39 |
| @dfajfer:fsfe.org | I'm not too sure regarding default Gerrit strategy as I can only configure the submit type | 16:39 |
| @dfajfer:fsfe.org | * I'm not too sure regarding default Gerrit merge strategy as I can only configure the submit type | 16:39 |
| @clarkb:matrix.org | on the zuul side you can configure a merge-mode. For Gerrit the default is merge-resolve. I just wanted to double check we aren't trying to cherry-pick or something | 16:44 |
| @dfajfer:fsfe.org | `You can control the merge strategy by configuring the submit type` confirming it's the same thing | 16:46 |
| @dfajfer:fsfe.org | I need to look into it, thanks Clark | 16:46 |
| @dfajfer:fsfe.org | > <@clarkb:matrix.org> on the zuul side you can configure a merge-mode. For Gerrit the default is merge-resolve. I just wanted to double check we aren't trying to cherry-pick or something | 16:47 |
| `If submit.action is not set, the default is 'merge if necessary'.` | ||
| @clarkb:matrix.org | thats the gerrit side. I'm talking about the zuul side. The zuul gerrit driver's default is merge-resolve which is zuul's attempt at mapping c git merging to jgit merging | 16:48 |
| @clarkb:matrix.org | zuul's config loading should all happen via merges performed by zuul itself so the merge methods configured in zuul are what matter here I think (they should align with your choices in gerrit though) | 16:48 |
| @dfajfer:fsfe.org | ohh, ok now it makes sense | 16:48 |
| @dfajfer:fsfe.org | I've checked Gerrit driver docs but I don't really see how is it configurable - https://zuul-ci.org/docs/zuul/latest/drivers/gerrit.html | 16:55 |
| @dfajfer:fsfe.org | I've also checked my configs so if what you speak is true I probably have a mismatch hence why I'm having this issue (ff only on Gerrit and merge if necessary on Zuul) | 16:56 |
| @dfajfer:fsfe.org | * I've also checked my configs so if what you speak is true I probably have a mismatch hence why I'm having this issue (ff only on Gerrit and merge if necessary on Zuul), because i'm not setting merge strategy on zuul side at all | 16:56 |
| @clarkb:matrix.org | https://zuul-ci.org/docs/zuul/latest/config/project.html#attr-project.merge-mode it is documented here | 16:57 |
| @clarkb:matrix.org | I think merge is correct for ff only? But I'm not sure we don't use ff only. (I think ff only is a variant of merge that means ensure merge is a noop) | 16:57 |
| @fungicide:matrix.org | yeah, ff-only would deadlock development on most of our projects, and a lot of zuul's functionality (particularly pipeline queuing/ordering) would be basically useless | 17:00 |
| @fungicide:matrix.org | i expect that's why there's not an equivalent merge-mode in zuul that would ensure every merge in a dependent queue is a no-op | 17:04 |
| @jim:acmegating.com | Clark: i think we should make 2 changes to the kafka change: | 17:43 |
| 1) we should disable the upgrade test since its trying to install the old version and can't. i'm surprised we don't hit this more often actually. | ||
| 2) i think we need to increase the wait timeouts on quickstart. i think maybe some image pulls are slower than they used to be, and we have containers starting up at more widely spaced times. we don't wait long enough for all of them to be running. | ||
| #2 isn't strictly necessary for this fix, but putting both things in one change will increase the chances of making through the gauntlet. | ||
| @jim:acmegating.com | * Clark: i think we should make 2 changes to the kafka change: | 17:43 |
| 1. we should disable the upgrade test since its trying to install the old version and can't. i'm surprised we don't hit this more often actually. | ||
| 2. i think we need to increase the wait timeouts on quickstart. i think maybe some image pulls are slower than they used to be, and we have containers starting up at more widely spaced times. we don't wait long enough for all of them to be running. | ||
| #2 isn't strictly necessary for this fix, but putting both things in one change will increase the chances of making through the gauntlet. | ||
| @jim:acmegating.com | fungi: ^ you too | 17:43 |
| -@gerrit:opendev.org- James E. Blair https://matrix.to/#/@jim:acmegating.com proposed: [zuul/zuul] 943021: Pin confluent-kafka https://review.opendev.org/c/zuul/zuul/+/943021 | 17:46 | |
| @clarkb:matrix.org | that seems reasonable | 17:47 |
| -@gerrit:opendev.org- James E. Blair https://matrix.to/#/@jim:acmegating.com proposed: [zuul/zuul] 943040: Re-enable upgrade job https://review.opendev.org/c/zuul/zuul/+/943040 | 17:47 | |
| -@gerrit:opendev.org- James E. Blair https://matrix.to/#/@jim:acmegating.com proposed: [zuul/zuul] 943022: Add librdkafka-dev to bindep https://review.opendev.org/c/zuul/zuul/+/943022 | 17:47 | |
| @clarkb:matrix.org | for the upgrade testing I half wonder if we should try something like start with the latest container version then switch over to current install talking to the same zk and directories but not necessarily in a container. | 17:48 |
| @clarkb:matrix.org | oh but we run inside the unitest env right? that might be tough to do with containers in that manner | 17:49 |
| @jim:acmegating.com | yeah, it's built around using unit tests | 17:49 |
| @jim:acmegating.com | one thing we could do perhaps to address this specific problem would be to try to install old-side deps, and if it fails, install new-side deps on the old side. | 17:50 |
| @clarkb:matrix.org | ya in general the new side may not always be applicable but as a fallback it could be reasonable | 17:50 |
| -@gerrit:opendev.org- Zuul merged on behalf of James E. Blair https://matrix.to/#/@jim:acmegating.com: [zuul/zuul] 943021: Pin confluent-kafka https://review.opendev.org/c/zuul/zuul/+/943021 | 19:39 | |
| -@gerrit:opendev.org- Zuul merged on behalf of James E. Blair https://matrix.to/#/@jim:acmegating.com: | 20:46 | |
| - [zuul/zuul] 942748: Fix cached quota calculation https://review.opendev.org/c/zuul/zuul/+/942748 | ||
| - [zuul/zuul] 942739: Delete node records as soon as practical https://review.opendev.org/c/zuul/zuul/+/942739 | ||
| - [zuul/zuul] 942860: Retry lock cleanup https://review.opendev.org/c/zuul/zuul/+/942860 | ||
| @aureliojargas:matrix.org | May I ask for a review in https://review.opendev.org/c/zuul/zuul-jobs/+/941490? It's the CR removing the code duplication for many of the `ensure-*` roles, unifying it in the new `ensure-python-command` role. | 22:16 |
| @aureliojargas:matrix.org | The diff is big, but at the end it's the same duplicated code being removed from many roles. | 22:16 |
Generated by irclog2html.py 2.17.3 by Marius Gedminas - find it at https://mg.pov.lt/irclog2html/!