| -@gerrit:opendev.org- James E. Blair https://matrix.to/#/@jim:acmegating.com proposed: [zuul/zuul] 824842: Update tenant layouts in background https://review.opendev.org/c/zuul/zuul/+/824842 | 00:16 | |
| -@gerrit:opendev.org- Felix Edel proposed: [zuul/zuul] 824864: Serialize FrozenJob.affected_projects to ZooKeeper https://review.opendev.org/c/zuul/zuul/+/824864 | 07:58 | |
| -@gerrit:opendev.org- Felix Edel proposed: [zuul/zuul] 824864: Serialize FrozenJob.affected_projects to ZooKeeper https://review.opendev.org/c/zuul/zuul/+/824864 | 09:14 | |
| @westphahl:matrix.org | corvus: one suggestion on 824842 | 11:02 |
|---|---|---|
| -@gerrit:opendev.org- chandan kumar proposed: [zuul/zuul-jobs] 822503: Introduce iptables_packages vars https://review.opendev.org/c/zuul/zuul-jobs/+/822503 | 13:17 | |
| -@gerrit:opendev.org- Simon Westphahl proposed: [zuul/zuul] 824938: Update build set states after scheduling actions https://review.opendev.org/c/zuul/zuul/+/824938 | 13:22 | |
| -@gerrit:opendev.org- chandan kumar proposed: [zuul/zuul-jobs] 822503: Introduce iptables_packages vars https://review.opendev.org/c/zuul/zuul-jobs/+/822503 | 13:59 | |
| -@gerrit:opendev.org- Simon Westphahl proposed: [zuul/zuul] 824938: Update build set states after scheduling actions https://review.opendev.org/c/zuul/zuul/+/824938 | 14:12 | |
| -@gerrit:opendev.org- chandan kumar proposed: [zuul/zuul-jobs] 822503: Introduce iptables_package var https://review.opendev.org/c/zuul/zuul-jobs/+/822503 | 14:44 | |
| @felixedel:matrix.org | corvus: Here is a small fix for a SOS bug we discovered today in our deployment: https://review.opendev.org/c/zuul/zuul/+/824864. I thought about a way to add a test for this as well, but I find it rather difficult. | 15:30 |
| @jim:acmegating.com | felixedel: qq on that -- should we make it a JobData attribute? i'm inclined to say yes... | 16:55 |
| @spamaps:spamaps.ems.host | Seems I've got some time to work on Zuul again this quarter. Going to resurrect that PoC and try to make it run with the GCP driver. Does anyone have a guide or some docs on how to run docker containers via Ansible? It shouldn't be too complicated but I'd love to get a head start from all of you excellent people. :) | 17:50 |
| -@gerrit:opendev.org- James E. Blair https://matrix.to/#/@jim:acmegating.com proposed: [zuul/zuul] 824842: Update tenant layouts in background https://review.opendev.org/c/zuul/zuul/+/824842 | 18:03 | |
| @clarkb:matrix.org | > <@spamaps:spamaps.ems.host> Seems I've got some time to work on Zuul again this quarter. Going to resurrect that PoC and try to make it run with the GCP driver. Does anyone have a guide or some docs on how to run docker containers via Ansible? It shouldn't be too complicated but I'd love to get a head start from all of you excellent people. :) | 18:33 |
| OpenDev does this by having Ansible trigger docker-compose. opendev/system-config/playbooks should have examples including for zuul itself | ||
| @clarkb:matrix.org | > <@clarkb:matrix.org> OpenDev does this by having Ansible trigger docker-compose. opendev/system-config/playbooks should have examples including for zuul itself | 18:34 |
| At a high level Ansible installs docker and docker-compose, writes out a docker-compose.yaml, then does a pull and up -d and optionally an image prune afterwards | ||
| @spamaps:spamaps.ems.host | > <@clarkb:matrix.org> At a high level Ansible installs docker and docker-compose, writes out a docker-compose.yaml, then does a pull and up -d and optionally an image prune afterwards | 18:38 |
| That is nice, that way we don't have to get in to the nitty gritty. What I'm dealing with is a rich set of "action container images" and so I just want to be able to let users specify a job of like `yarn-build-node-16` and it has a VM image with docker already up and running and all the action containers pulled that will just do `docker run yarn-build-node-16 ...` and then some post stuff to pull the resulting build image into GCS for the next step to grab it. | ||
| @spamaps:spamaps.ems.host | I don't think we'll need compose.. but as I typed that out I am realizing a lot of what I want to do will be in the VM image so that they're pre-built with as much ready to go as possible. We're fighting a really painful war against build time and the more we do before the PR is submitted, the better. | 18:39 |
| @spamaps:spamaps.ems.host | (Build time target is 15 minutes.. we're at 22.. we drift upward by about 1 minute per month) | 18:40 |
| @clarkb:matrix.org | > <@spamaps:spamaps.ems.host> That is nice, that way we don't have to get in to the nitty gritty. What I'm dealing with is a rich set of "action container images" and so I just want to be able to let users specify a job of like `yarn-build-node-16` and it has a VM image with docker already up and running and all the action containers pulled that will just do `docker run yarn-build-node-16 ...` and then some post stuff to pull the resulting build image into GCS for the next step to grab it. | 18:40 |
| Ah ya our stuff is far more long lived service oriented. We run things the way I describe in CI and production. But the expectation is more this service exists for a while. Not sure if the same docker compose setup makes sense for action containers. It might | ||
| @spamaps:spamaps.ems.host | The system we have in place only gives every build one huge honking jenkins worker. So just decomposing it into Zuul jobs that can run independently should be a win. | 18:40 |
| @spamaps:spamaps.ems.host | And then we also need to have a clear set of job avoidance rules, since it's a monorepo. | 18:42 |
| @spamaps:spamaps.ems.host | (the fun part is that it may be deconstructed into 7 micro-site repos but Zuul would actually help with that *a lot*) | 18:42 |
| @spamaps:spamaps.ems.host | As the main reason people are avoiding deconstructing is testing changes to the shared code. | 18:43 |
| @jim:acmegating.com | that is decidedly in zuul's wheelhouse :) | 18:46 |
| @avass:vassast.org | spamaps: If you have fat images it could be as simple as letting the users write their own build scripts (like calling a shell script from ansible) and making sure everything they need is already cached on the VM image. That way the build wouldn't be dependent on being run by zuul and could also be useful to build locally | 19:03 |
| @avass:vassast.org | I mean, that way you can just call a shell script from zuuls ansible instead of being dependent on ansible to build :) | 19:06 |
| @spamaps:spamaps.ems.host | > <@avass:vassast.org> spamaps: If you have fat images it could be as simple as letting the users write their own build scripts (like calling a shell script from ansible) and making sure everything they need is already cached on the VM image. That way the build wouldn't be dependent on being run by zuul and could also be useful to build locally | 19:08 |
| Oh 100%. The idea is exactly that. Give a generic interface just like the action container interface they have now so we can move jobs to Zuul incrementally while we're evaluating. | ||
| -@gerrit:opendev.org- James E. Blair https://matrix.to/#/@jim:acmegating.com proposed: | 21:05 | |
| - [zuul/zuul] 817626: Remove rpcclient from autohold tests https://review.opendev.org/c/zuul/zuul/+/817626 | ||
| - [zuul/zuul] 819699: Remove rpcclient tests https://review.opendev.org/c/zuul/zuul/+/819699 | ||
| - [zuul/zuul] 819700: Remove rpcclient use from github tests https://review.opendev.org/c/zuul/zuul/+/819700 | ||
| - [zuul/zuul] 819701: Remove rpcclient from gitlab tests https://review.opendev.org/c/zuul/zuul/+/819701 | ||
| - [zuul/zuul] 819702: Remove rpcclient from pagure tests https://review.opendev.org/c/zuul/zuul/+/819702 | ||
| - [zuul/zuul] 819703: Remove rpcclient from test_reporting https://review.opendev.org/c/zuul/zuul/+/819703 | ||
| - [zuul/zuul] 819704: Remove rpcclient from test_v3 https://review.opendev.org/c/zuul/zuul/+/819704 | ||
| - [zuul/zuul] 819705: Remove rpcclient from test_web https://review.opendev.org/c/zuul/zuul/+/819705 | ||
| - [zuul/zuul] 819706: Remove rpcclient from test_zuulclient https://review.opendev.org/c/zuul/zuul/+/819706 | ||
| - [zuul/zuul] 819707: Remove rpcclient from test_circular_dependencies https://review.opendev.org/c/zuul/zuul/+/819707 | ||
| - [zuul/zuul] 819708: Remove rpcclient from connection test fixtures https://review.opendev.org/c/zuul/zuul/+/819708 | ||
| - [zuul/zuul] 819709: Remove the rpc client and listener https://review.opendev.org/c/zuul/zuul/+/819709 | ||
| - [zuul/zuul] 819710: Remove disused gearman_server usages from tests https://review.opendev.org/c/zuul/zuul/+/819710 | ||
| - [zuul/zuul] 819711: Remove gearman server https://review.opendev.org/c/zuul/zuul/+/819711 | ||
| - [zuul/zuul] 819712: Remove gearman from docs https://review.opendev.org/c/zuul/zuul/+/819712 | ||
| -@gerrit:opendev.org- James E. Blair https://matrix.to/#/@jim:acmegating.com proposed: | 21:34 | |
| - [zuul/zuul] 819711: Remove gearman server https://review.opendev.org/c/zuul/zuul/+/819711 | ||
| - [zuul/zuul] 819712: Remove gearman from docs https://review.opendev.org/c/zuul/zuul/+/819712 | ||
| - [zuul/zuul] 825014: Remove "sql connection" backwards compatability for database https://review.opendev.org/c/zuul/zuul/+/825014 | ||
| @jim:acmegating.com | that's a rebase of the gearman removal stack, and that last change is a new additional deprecation cleanup. any others we should take care of for 5.0 while we're at it? | 21:36 |
| @clarkb:matrix.org | Should we deprecate python <3.8? | 22:25 |
| @clarkb:matrix.org | That can be stacked atop the gearman removal with a shift to focal. I think CentOS 8 is the main reason to support 3.6. May be worth keeping but it doing a major release now is the time to consider it | 22:26 |
| @clarkb:matrix.org | I think that the openshift testing may rely on CentOS fwiw | 22:26 |
| -@gerrit:opendev.org- James E. Blair https://matrix.to/#/@jim:acmegating.com proposed: | 23:22 | |
| - [zuul/zuul] 825022: Add a model API version https://review.opendev.org/c/zuul/zuul/+/825022 | ||
| - [zuul/zuul] 825023: DNM: Example model upgrade change https://review.opendev.org/c/zuul/zuul/+/825023 | ||
Generated by irclog2html.py 2.17.3 by Marius Gedminas - find it at https://mg.pov.lt/irclog2html/!