*** ysandeep|out is now known as ysandeep|PTO | 00:05 | |
*** rlandy is now known as rlandy|out | 00:32 | |
*** yadnesh|away is now known as yadnesh | 04:19 | |
*** bhagyashris is now known as bhagyashris|ruck | 06:24 | |
*** jpena|off is now known as jpena | 07:37 | |
*** rlandy|out is now known as rlandy | 10:31 | |
*** sean-k-mooney1 is now known as sean-k-mooney | 11:31 | |
opendevreview | Vishal Manchanda proposed openstack/openstack-zuul-jobs master: Add nodejs v18 project templates for 2023.1 release https://review.opendev.org/c/openstack/openstack-zuul-jobs/+/861876 | 11:40 |
---|---|---|
*** frenzy_friday is now known as frenzyfriday|rover | 12:52 | |
*** dasm|off is now known as dasm | 13:55 | |
opendevreview | Felipe Reyes proposed openstack/project-config master: Create 'Backport-Candidate' for Charms repos https://review.opendev.org/c/openstack/project-config/+/861892 | 14:29 |
coreycb | clarkb: jammy has python version 3.11.0~rc1-1~22.04 | 15:02 |
clarkb | oh neat, I thought I had looked and didn't find one. But I used package search and not aptitude search against the indexes | 15:08 |
coreycb | clarkb: actually it's in jammy-proposed so you may have | 15:09 |
*** ykarel is now known as ykarel|afk | 15:27 | |
*** dviroel is now known as dviroel|lunch | 15:46 | |
*** ykarel|afk is now known as ykarel | 15:48 | |
fungi | for some reason, puc is giving me a 5xx error when i search for keyword "python3.11" | 16:16 |
tonyb | This may be better asked in https://matrix.to/#/#zuul:opendev.org but I'll start here as it's for the requirements repo. | 16:25 |
tonyb | Are there good examples / docs on building a multi-node job where each node runs a different OS (eg CentOS8, Focal, Jammy) that each run $commands to generate an artifact, and then a dependant job that grabs and collates each artifact ? | 16:27 |
*** dviroel|lunch is now known as dviroel | 16:28 | |
fungi | tonyb: the short explanation is you need to create a custom nodeset which lists (and optionally renames) the nodes you want included and what labels (images) they're based on | 16:30 |
fungi | i can get you simple examples, just a sec | 16:31 |
tonyb | Thanks fungi | 16:32 |
fungi | tonyb: here's an example of doing it anonymously within a job, though you can also create named nodesets and refer to those in your jobs if you need to reuse them: https://opendev.org/opendev/system-config/src/branch/master/zuul.d/system-config-run.yaml#L60-L71 | 16:34 |
fungi | that one's a fairly extreme case, but shows you a 5-node group using 4 different labels | 16:35 |
fungi | the only real caveat is that there needs to be at least one node provider which has all the labels you use, since nodesets can't span providers | 16:36 |
fungi | but if you're using our generic labels that's generally not an issue | 16:37 |
tonyb | Ok that makes sense, I have no idea how to do the second part. Grabbing some artifact that each of those nodes create. | 16:37 |
fungi | if it has the same name then you just need a task which grabs the file and apply it to "all" hosts, but there's almost certainly a standard role already in zuul-jobs which does what you need in that regard | 16:39 |
tonyb | Okay I'll go grepping | 16:40 |
fungi | tonyb: here's an example build which collected similarly-named things from multiple nodes: https://zuul.opendev.org/t/openstack/build/b5b1691da7d241d792bd65564b9d9c63/logs | 16:44 |
fungi | though you can see the same process at work in multinode devstack jobs too | 16:45 |
*** jpena is now known as jpena|off | 16:45 | |
fungi | check out the console tab from that build and expand the post playbooks | 16:46 |
fungi | there you can see the roles/tasks which ran to fetch the files from each node | 16:46 |
tonyb | fungi: Thanks | 16:49 |
fungi | tonyb: this may be the one you want https://zuul-ci.org/docs/zuul-jobs/general-roles.html#role-stage-output | 16:50 |
tonyb | That looks good. .... and there's a small docs fix coming :) | 16:55 |
*** yadnesh is now known as yadnesh|away | 17:14 | |
elodilles | clarkb fungi : if there is nothing planned for now, then i'd run the EOL branch clean up script to delete ironic project's rocky & stein branches (which by the way will eliminate some zuul config errors \o/) | 17:43 |
clarkb | elodilles: I have nothing right now. I do need to restart gerrit at some point to pick up some gerrit plugin cleanups in the newer images, but that will be late today when thingsare quiet if I get to it | 17:44 |
elodilles | clarkb: ack, thanks, then i'll run the script now and then it won't interfere with the gerrit restart | 17:48 |
fungi | yeah, sounds good! | 18:01 |
elodilles | clarkb: the script has finished (deleted branches: https://paste.opendev.org/show/bm23cSgmfWzurR93gEkr/ ) | 18:20 |
clarkb | elodilles: thanks for the heads up | 18:21 |
fungi | also yay for more zuul config errors and periodic job failures going away! | 18:22 |
frickler | tonyb: actually I think you don't need multiple jobs. just run the u-c generation on the different nodes as one task and then do the aggregation on one of those node or maybe on the executor directly | 18:47 |
fungi | yes, i assumed it would be: test nodes generate constraints lists, executor combines lists and uploads | 19:01 |
fungi | i agree that doing it as multiple jobs is overkill | 19:02 |
fungi | if you wanted to avoid having multi-node jobs, you could generate each constraints sublist in a separate single-node job which creates an artifact, and then have a zero-node job depending on those which retrieves and combines them | 19:03 |
fungi | the only thing i'm not sure about is if we can do patch proposals from the executor, but yes you can always just pick a specific test node and make those change proposal tasks only relevant for that one | 19:04 |
*** dviroel is now known as dviroel|biab | 20:47 | |
tonyb | okay. I think I understand. | 21:28 |
tonyb | I'll write up a dummy set of plays and a small doc to make sure I do. and then I'll figure out the real implementation. | 21:28 |
fungi | that sounds like a great way to sketch it out | 21:38 |
*** dviroel|biab is now known as dviroel | 21:59 | |
*** dasm is now known as dasm|off | 22:19 | |
*** dviroel is now known as dviroel|out | 23:03 |
Generated by irclog2html.py 2.17.3 by Marius Gedminas - find it at https://mg.pov.lt/irclog2html/!