| @mnaser:matrix.org | i presume if i remembe right nodepool still out of the box does not want to give you a nodeset from two different providers out of the box | 19:23 |
|---|---|---|
| @mnaser:matrix.org | im working out image builds and trying to get a nodeset of 2 vms, one that does amd64 and one that does arm64 to have faster buildx builds natively | 19:24 |
| @clarkb:matrix.org | Yes the nodeset has to be fulfilled by one provider | 19:34 |
| @clarkb:matrix.org | You could aggregate the images together in a child job which would give everything a different nodeset. | 19:34 |
| @jim:acmegating.com | mnaser: is this in opendev? | 19:41 |
| @mnaser:matrix.org | would like to :) but since it's testing github its our own deployment at zuul.oss.vexxhost.dev | 19:42 |
| @jim:acmegating.com | mnaser: your cloud or someone else's? | 19:42 |
| @mnaser:matrix.org | x86 would be from ours, arm from aws (not ideal but a quick bandaid) | 19:43 |
| @jim:acmegating.com | got it. (i was wondering why in your situation the providers would be different, i see now). then yeah, not much to add to what Clark said. | 19:44 |
| @mnaser:matrix.org | i guess the only other easier bandaid is to run x86 on aws for this specific thing if i want to avoid having a 3rd manifest merge job to avoid passing around a lot of artifacts | 19:45 |
| @jim:acmegating.com | yeah. i figure zuul-launcher will probably be ready for wider use in another month or so if that helps prioritize effort. it will be able to do cross-provider requests. | 19:46 |
| @mnaser:matrix.org | happy to be one of the ones to field that first.. i think maybe for now we live with slower build times to save on the headache.. emulation for these bigger image builds we do is really hurting | 19:47 |
| @mnaser:matrix.org | though i guess for our case it is worth seeing if we can eliminate it because we're mostly packaging openstack so its just installing and extracting wheels.. so i wonder if we can build a venv for another platform (cross-platform) for example | 19:47 |
| @mnaser:matrix.org | and the package installations maybe we use debootstrap or something that doesnt involve needing to run binaries of that actual architecture.. | 19:48 |
| @jangutter:matrix.org | mnaser: sorry to bother, but this one lost your +2 after incorporating a suggestion from Clark https://review.opendev.org/c/zuul/zuul-jobs/+/962794 | 19:55 |
| @clarkb:matrix.org | mnaser: we build nodepool images using the qemu emulation and it isn't fast but works well enough as long as you are primarily doing io | 19:59 |
| @clarkb:matrix.org | Once you start compiling stuff it doesn't work great | 19:59 |
| @mnaser:matrix.org | i've found stuff like even apt-get installs taking ages as emulated, and we build quite often, since we do bumps of openstack services quite often to the tip of stable branch | 20:00 |
| @mnaser:matrix.org | so we're looking at maybe an hour of building | 20:00 |
| @jangutter:matrix.org | The scariest thing with my M4 is that building x86 images on it isn't _too_ slow. But building arm64 images on my x86 is a proper slog. | 20:08 |
| @mnaser:matrix.org | yeah i've seen similar results as well, kinda interesting.. | 20:13 |
| @jangutter:matrix.org | My rabbit hole of the day: https://www.linaro.org/blog/qemu-a-tale-of-performance-analysis/ "To answer the initial question that led to this investigation, it’s possible to boot an Android guest in less than 5 minutes on modern hardware." | 20:23 |
| -@gerrit:opendev.org- Zuul merged on behalf of Jan Gutter: [zuul/zuul-jobs] 962794: Update ensure-helm role to add more functionality https://review.opendev.org/c/zuul/zuul-jobs/+/962794 | 20:30 | |
Generated by irclog2html.py 4.0.0 by Marius Gedminas - find it at https://mg.pov.lt/irclog2html/!