| -@gerrit:opendev.org- Zuul merged on behalf of James E. Blair https://matrix.to/#/@jim:acmegating.com: [zuul/zuul] 922778: Add exclude_results to buildsets api https://review.opendev.org/c/zuul/zuul/+/922778 | 00:13 | |
| -@gerrit:opendev.org- Simon Westphahl proposed: [zuul/zuul] 924695: Deprecate and cleanup use of status-url https://review.opendev.org/c/zuul/zuul/+/924695 | 06:41 | |
| -@gerrit:opendev.org- Jan Gutter proposed: | 10:17 | |
| - [zuul/zuul-operator] 924748: Minor fixes and dependency updates https://review.opendev.org/c/zuul/zuul-operator/+/924748 | ||
| - [zuul/zuul-operator] 924872: Change references from docker.io to quay.io https://review.opendev.org/c/zuul/zuul-operator/+/924872 | ||
| -@gerrit:opendev.org- Jan Gutter proposed: | 13:13 | |
| - [zuul/zuul-operator] 924748: Minor fixes and dependency updates https://review.opendev.org/c/zuul/zuul-operator/+/924748 | ||
| - [zuul/zuul-operator] 924872: Change references from docker.io to quay.io https://review.opendev.org/c/zuul/zuul-operator/+/924872 | ||
| -@gerrit:opendev.org- Dong Zhang proposed: [zuul/nodepool] 924931: Fix backing node not released correctly in race condition https://review.opendev.org/c/zuul/nodepool/+/924931 | 13:26 | |
| -@gerrit:opendev.org- Dong Zhang proposed: [zuul/nodepool] 924932: Fix backing node not released correctly in race condition https://review.opendev.org/c/zuul/nodepool/+/924932 | 13:28 | |
| -@gerrit:opendev.org- Dong Zhang proposed: [zuul/nodepool] 924932: Fix backing node not released correctly in race condition https://review.opendev.org/c/zuul/nodepool/+/924932 | 13:30 | |
| -@gerrit:opendev.org- Dong Zhang proposed: [zuul/nodepool] 924932: Fix backing node not released correctly in race condition https://review.opendev.org/c/zuul/nodepool/+/924932 | 13:31 | |
| -@gerrit:opendev.org- Dong Zhang proposed: [zuul/nodepool] 924932: WIP: Fix backing node not released correctly in race condition https://review.opendev.org/c/zuul/nodepool/+/924932 | 13:54 | |
| -@gerrit:opendev.org- Simon Westphahl proposed: [zuul/zuul] 924937: wip: prototype statemachine serialization https://review.opendev.org/c/zuul/zuul/+/924937 | 13:56 | |
| @jangutter:matrix.org | So TIL that if you use docker engine, then using quay.io as an intermediate registry won't work: https://github.com/moby/moby/issues/18818 | 13:59 |
|---|---|---|
| -@gerrit:opendev.org- James E. Blair https://matrix.to/#/@jim:acmegating.com proposed: [zuul/zuul] 924792: Unify provider validation and deserialization schemas https://review.opendev.org/c/zuul/zuul/+/924792 | 14:08 | |
| @jim:acmegating.com | strictly speaking, it's the buildset registry, but yes. that's why there's two sets of jobs, one for dockerland and one for not-dockerland. the whole setup used to work with k8s and quay or dockerhub, due to the way k8s used the containers-project config files, but something changed. | 14:16 |
| @jangutter:matrix.org | Yeh, I'm thinking of trying minikube+podman+cri-o (that's the setup on c9 I've got in our lab) | 14:17 |
| @jim:acmegating.com | nice; we know podman works well. | 14:18 |
| @jangutter:matrix.org | Another problem though, the docker.io job does seem to be flakey as heck - not sure why, but minikube seems to be the opposite of stable. Possibly resource constraint? Possible io bottleneck? | 14:20 |
| @dfajfer:fsfe.org | doesn't docker.io impose restrictions on download speed | 14:20 |
| -@gerrit:opendev.org- James E. Blair https://matrix.to/#/@jim:acmegating.com proposed: [zuul/zuul] 923084: WIP: Try docker compose with podman https://review.opendev.org/c/zuul/zuul/+/923084 | 14:21 | |
| @jim:acmegating.com | jangutter: which job? | 14:22 |
| @jangutter:matrix.org | * Another problem though, the zuul-operator functional test docker.io job does seem to be flakey as heck - not sure why, but minikube seems to be the opposite of stable. Possibly resource constraint? Possible io bottleneck? | 14:23 |
| @jangutter:matrix.org | > <@jim:acmegating.com> jangutter: which job? | 14:23 |
| https://review.opendev.org/c/zuul/zuul-operator/+/924748 | ||
| In this case there's been three separate failures, not related to container pulling: | ||
| 1. etcd flaked out. I've seen this before when disk io is constrained and it hits a timeout or so. | ||
| 2. zookeeper didn't get its persistent volume claim satisfied and timed out | ||
| 3. console log glitch (this one I've seen in our lab, haven't tracked down why, suspect it's a race in the test) | ||
| @jangutter:matrix.org | I'm only looking at the zuul-operator so far, and approaching it from a perspective of complete noob. | 14:24 |
| @dfajfer:fsfe.org | operator is cool but you need help to run it | 14:25 |
| @dfajfer:fsfe.org | I've set up several environments using the operator, I'm planning to submit them by the end of the week | 14:26 |
| @dfajfer:fsfe.org | * I've set up several environments using the operator, I'm planning to submit fixes by the end of the week | 14:26 |
| @jim:acmegating.com | jangutter: opendev does have something like 6 cloud providers; it's possible that variations in node resources could be contributing. you can see what's used in the inventory file. | 14:26 |
| @jangutter:matrix.org | Yeah, we're trying to select between sf-operator, zuul-operator or pure helm charts. If we can get the operator's CI back up and running that's a big plus. | 14:27 |
| @jangutter:matrix.org | > <@jim:acmegating.com> jangutter: opendev does have something like 6 cloud providers; it's possible that variations in node resources could be contributing. you can see what's used in the inventory file. | 14:27 |
| I noticed minikube seems to be able to detect kvm or xen, so I assumed as much! | ||
| @dfajfer:fsfe.org | I won't be objective as I've chosen zuul-operator but I've found it to be cool because of QoL stuff such as auto-loading tenant configuration | 14:29 |
| @dfajfer:fsfe.org | I'd need to compare what am I missing as I've been using zuul kubernetes operator for years now | 14:30 |
| -@gerrit:opendev.org- Damian Fajfer proposed: [zuul/zuul-operator] 924959: Add support for custom images and secrets in external dependencies https://review.opendev.org/c/zuul/zuul-operator/+/924959 | 17:44 | |
| @dfajfer:fsfe.org | ^ regarding this, I'm new to contributing here. I've created a storyboard[1] but I'm not sure if you can link them somehow | 17:47 |
| [1] https://storyboard.openstack.org/#!/story/2011182 | ||
| @clarkb:matrix.org | something I noticed looking at our cron email: Cryptography 48.0.0 will (re)move some things that paramiko appears to be relying on which must happen at import time? We get the warning when we do zk backups | 17:52 |
| @clarkb:matrix.org | this is for nodepool specifically. Anyway might be good to check that paramiko isn't pinning or something like that to avoid breaking in the future | 17:52 |
| @jim:acmegating.com | Damian Fajfer: thanks! you can say "Story: 2011182" but it's not necessary, we don't use it much except for security things. also, it might be a while before there is movement on your change since the zuul-operator tests are currently broken. | 17:58 |
| @jim:acmegating.com | Clark: i think that's showing up in the unit test runs too | 17:58 |
| @jim:acmegating.com | https://zuul.opendev.org/t/zuul/build/418cdcd6b4f141de9a3d162aa6be4113/log/job-output.txt#6610 | 17:58 |
| @clarkb:matrix.org | yup that looks the same | 17:59 |
| @jim:acmegating.com | btw, one of the nice things about the poetry stuff mordred has been playing with is that it allows one to answer the question "what caused me to end up with version X of Y?" | 18:00 |
| @jim:acmegating.com | anyway, we aren't pinning either of those directly, so if something is pinned, it's indirect | 18:00 |
| @jim:acmegating.com | https://github.com/paramiko/paramiko/issues/2419 | 18:01 |
| @clarkb:matrix.org | I think that pip does report some of that info but only when you don't also list the dependency | 18:02 |
| @clarkb:matrix.org | so its only included for truly transitive deps | 18:02 |
| @jim:acmegating.com | looks like it's just paramiko needs to update to new api | 18:02 |
| @jim:acmegating.com | https://github.com/paramiko/paramiko/pull/2421 | 18:03 |
| @clarkb:matrix.org | its a little scary that people think pinning cryptography is a valid workaround (you can silence warnings instead which is much safer) | 18:03 |
| @jim:acmegating.com | yeah... that wasn't pretty | 18:03 |
| @dfajfer:fsfe.org | > <@jim:acmegating.com> Damian Fajfer: thanks! you can say "Story: 2011182" but it's not necessary, we don't use it much except for security things. also, it might be a while before there is movement on your change since the zuul-operator tests are currently broken. | 18:04 |
| yeah we've spoken about it:) I'm still going to commit everything I fixed so far and the eventually take a look at the CI | ||
| @dfajfer:fsfe.org | I just had to do it asap at work | 18:04 |
| @dfajfer:fsfe.org | going with `Story: 2011182` won't link it right? | 18:04 |
| @jim:acmegating.com | Damian Fajfer: no prob; just so long as your expectations are set appropriately | 18:04 |
| @jim:acmegating.com | Damian Fajfer: it should add a link if you put that in the commit message (i think? it's been a long time since i did) | 18:05 |
| -@gerrit:opendev.org- Damian Fajfer proposed: [zuul/zuul-operator] 924959: Add support for custom images and secrets in external dependencies https://review.opendev.org/c/zuul/zuul-operator/+/924959 | 18:05 | |
| @dfajfer:fsfe.org | it does link | 18:05 |
| @dfajfer:fsfe.org | one-way but still better than nothing | 18:05 |
| @jim:acmegating.com | assuming everything still works, it may actually be a 2-way link | 18:05 |
| @jim:acmegating.com | but the story task is already assigned to you, so there's probably nothing to do | 18:06 |
| @jim:acmegating.com | Damian Fajfer: anyway, that looks good, though usually folks put all the "footers" together at the bottom, with the Change-Id | 18:06 |
| @dfajfer:fsfe.org | oh, well. I always got bullied for not highlighting jira ticket high enough and it being on a 3rd line became standard for me | 18:07 |
| @dfajfer:fsfe.org | sure, I can switch to that since I'm gonna commit some more anyways | 18:08 |
| -@gerrit:opendev.org- Damian Fajfer proposed: [zuul/zuul-operator] 924959: Add support for custom images and secrets in external dependencies https://review.opendev.org/c/zuul/zuul-operator/+/924959 | 18:08 | |
| @jim:acmegating.com | oh that's interesting. no bullying here though; we don't care enough to reject a change for something like that. just sharing the local customs. :) | 18:09 |
| @dfajfer:fsfe.org | I wasn't worried about upsetting someone:) I just don't recall seeing a commit with `Story` inside | 18:09 |
| @dfajfer:fsfe.org | in rome do as romans do | 18:10 |
| @dfajfer:fsfe.org | > <@gerrit:opendev.org> Jan Gutter proposed: | 18:18 |
| > - [zuul/zuul-operator] 924748: Minor fixes and dependency updates https://review.opendev.org/c/zuul/zuul-operator/+/924748 | ||
| > - [zuul/zuul-operator] 924872: Change references from docker.io to quay.io https://review.opendev.org/c/zuul/zuul-operator/+/924872 | ||
| these are already implemented in another commits | ||
| @dfajfer:fsfe.org | you just bundled them together | 18:18 |
| -@gerrit:opendev.org- Damian Fajfer proposed: [zuul/zuul-operator] 924965: Upgrade Percona from 1.11 to 1.14 https://review.opendev.org/c/zuul/zuul-operator/+/924965 | 18:23 | |
| -@gerrit:opendev.org- Jan Gutter proposed: [zuul/zuul-jobs] 924970: Update ensure-kubernetes with podman support https://review.opendev.org/c/zuul/zuul-jobs/+/924970 | 19:07 | |
| @fungicide:matrix.org | > <@dfajfer:fsfe.org> going with `Story: 2011182` won't link it right? | 19:19 |
| storyboard has a concept of stories which consist of multiple tasks. a story is potentially cross-project while tasks are project-specific (and there can be multiple tasks in a story for the same project). if you want a change in review.opendev.org to update a particular task you can use "task: NNNNN" with the actual task id number | ||
| -@gerrit:opendev.org- James E. Blair https://matrix.to/#/@jim:acmegating.com proposed: [zuul/zuul] 924807: Add configure-projects https://review.opendev.org/c/zuul/zuul/+/924807 | 21:16 | |
| @clarkb:matrix.org | I've started looking at gerrit 3.10 release notes to try and make sense of how painful an upgrade will be (there are a lot of changes in this release it seems like). One of the things I've noticed is they have deprecated robot comments and the implication seems to be that CI systems are expected to use teh checks framework. I think this means robot comments are still fine in 3.10, but at some point (not sure how soon) zuul may need to stop using them and rely on the checks framework. This might require us to write a zuul checks framework plugin for gerrit | 21:50 |
| @clarkb:matrix.org | The thing that is confusing to me is deprecating robot comments is listed as a breaking change: https://www.gerritcodereview.com/3.10.html#breaking-changes which half implies to me that not only did they deprecate the functionality they removed it? Is anyone running Zuul with Gerrit 3.10 yet? | 21:51 |
| @clarkb:matrix.org | I've also asked for clarification on the upstream discord but doing so is a bit clunky so half hoping people in here know the answers :) | 21:54 |
| @clarkb:matrix.org | Oh another interesting thing is the checks api framework is for supplying CI results to the change pages but not necessarily for controlling mergability. Mergability is determed by CI system votes (currently provided by robot comments I think) | 21:58 |
| @jim:acmegating.com | Clark: i think votes are separate from robot comments; the robot comments are just line-level comments. so if they finally do yank them, we'll just turn off the extra bits there and they will show up as human comments. hardest part of that will be deciding whether they should be resolved by default. | 23:10 |
| @jim:acmegating.com | * Clark: votes are separate from robot comments; the robot comments are just line-level comments. so if they finally do yank them, we'll just turn off the extra bits there and they will show up as human comments. hardest part of that will be deciding whether they should be resolved by default. | 23:11 |
| @jim:acmegating.com | * Clark: label votes are separate from robot comments; the robot comments are just line-level comments. so if they finally do yank them, we'll just turn off the extra bits there and they will show up as human comments. hardest part of that will be deciding whether they should be resolved by default. | 23:11 |
| @clarkb:matrix.org | got it | 23:13 |
Generated by irclog2html.py 2.17.3 by Marius Gedminas - find it at https://mg.pov.lt/irclog2html/!