| *** bauzas_ is now known as bauzas | 01:33 | |
| *** bauzas_ is now known as bauzas | 08:14 | |
| *** bauzas_ is now known as bauzas | 10:52 | |
| dansmith | clarkb: fungi: can you point me at an example job with a publish-to-static.o.o example or otherwise help me with that fu? | 13:53 |
|---|---|---|
| dansmith | also, my job currently doesn't collect these images as artifacts, intentionally, because I figure it's best not to store them on logs.o.o for no reason.. let me know if that's misguided | 13:54 |
| fungi | dansmith: generic documentation building/publication jobs are an example, but maybe not conveniently encapsulated due to having a lot of layers of inheritance, i'll see if i can find you something more concise | 13:59 |
| dansmith | fungi: are the docs. and static. the same procedure? | 14:00 |
| dansmith | I had the docs ones open so I could go look at those | 14:00 |
| fungi | yes, identical | 14:00 |
| dansmith | I also, I dunno, guessed that I needed some admin intervention? :) | 14:00 |
| fungi | as for temporarily collecting the built images as artifacts for upload to swift, zuul doesn't have its own temporary storage so swift is where we make that happen. things are uploaded with an expiration set so they get auto-deleted after 30 days anyway and it's not like this job is going to run all that often once you're done ironing out the specifics | 14:01 |
| dansmith | I meant collecting logs so they show up on logs.o.o | 14:01 |
| dansmith | personally, I see no reason to store them like that and that's kinda the whole point of the scripting, but it was asked in review :) | 14:02 |
| fungi | logs.o.o isn't a thing any more. zuul uploads logs and artifacts to swift, along with a manifest telling it which should be treated as what (log files, artifacts...) | 14:02 |
| dansmith | oh | 14:03 |
| fungi | when you use zuul's webui to browse/view logs or artifacts, they're just served to you directly from swift (potentially with some client-side rendering applied) | 14:03 |
| dansmith | I see now | 14:03 |
| fungi | having the temporary copy in swift and then the final copy synced into afs is somewhat duplicative, but the copies in swift expire and are automatically reaped so it's not a big deal | 14:04 |
| dansmith | okay | 14:05 |
| fungi | the gate job which produces your image and the promote job which "publishes" (pulls from swift and pushes into afs) are quite likely to run in completely separate clouds from different zuul executors so there's no better place to temporarily store them for async operation like that | 14:05 |
| dansmith | okay I'm a bit lost then, the gate job can't do the publish? I guess I need to see where these publish jobs are queued? | 14:07 |
| fungi | anyway, back to the admin intervention part, some projects are already publishing non-tarball files like minimal server images and container images to the tarballs site, so we might just increase the quota on its volume if you want to serve these from a subdirectory there. if you want a totally different domain name or a top-level subdirectory on static.opendev.org we'd need to add a | 14:07 |
| fungi | new volume for it, but that's also pretty easy | 14:07 |
| dansmith | static.o.o seems like the right thing (these aren't tarballs) | 14:08 |
| dansmith | even though existing sins are being committed, but you tell me :) | 14:08 |
| fungi | dansmith: the way the docs jobs work, as an example, is that the gate job builds the documentation and then creates a tarball of that file tree and archives it into swift along with the job logs and such. if the gate job succeeds and the change then merges, a promote pipeline job runs which gets the artifact url reference passed in by zuul, retrieves the tarball from swift, unpacks it, | 14:09 |
| fungi | then performs an rsync into afs | 14:09 |
| dansmith | okay, seems like that's going to require me to land stuff, then land the gate+publish job, and if it doesn't work, land more stuff to try again, yeah? | 14:10 |
| dansmith | looking through the docs publish stuff I'm clearly going to have to spend some time studying this to grok | 14:11 |
| fungi | the utility of that approach is less obvious for documentation builds, but if you extend that same pattern to something where you might want to test the built artifacts in the gate, perhaps by a completely separate but dependent gate job, then that gives you the ability to perform acceptance testing on built artifacts and only publish if they're deemed safe and working | 14:11 |
| fungi | also, and importantly for us, it isolates the publication credential access completely from whatever code is running to do the building and testing | 14:12 |
| fungi | so we can have a very simple and completely locked-down job that just gets artifacts and publishes them somewhere without running arbitrary untrusted code in the same place | 14:13 |
| dansmith | sure, makes sense | 14:13 |
| fungi | on the subject of using https://static.opendev.org/ as the url for other projects' jobs to access your sample images, if you look at that site it's basically just a raw view of the global /afs/openstack.org file tree (naming of our afs cell is openstack-specific because it pre-dates the existence of opendev and is hard to change). under that you'll see that docs.openstack.org has its | 14:18 |
| fungi | own "docs" top-level directory, again for historical reasons, but most other sites are inside the "project" directory | 14:18 |
| dansmith | okay so you're thinking project/tarballs.opendev.org/openstack/os-test-images/ ? | 14:21 |
| fungi | as an example, https://static.opendev.org/project/tarballs.opendev.org/openstack/heat-test-image/ is a.k.a. https://tarballs.opendev.org/openstack/heat-test-image/ | 14:21 |
| fungi | static.o.o is simply giving a higher-level view of the various web vhosts served from the same apache server | 14:22 |
| dansmith | yeah, understand.. feels wrong to have "tarballs" anywhere in the url for this, but I get it :) | 14:23 |
| fungi | devstack used to pull that for certain jobs, but i think it stopped a while back, don't remember how long ago. i expect we could clean that up. i think ipa was also publishing coreos images on the tarballs site | 14:23 |
| fungi | kolla used to as well, but have switched to just depending on dockerhub leaving behind this breadcrumb now: https://tarballs.opendev.org/openstack/kolla/images/README.txt | 14:24 |
| dansmith | ack, if there's some simpler targeted job I could look at to get my bearings that would be great | 14:25 |
| dansmith | the docs stuff looks fairly complicated | 14:25 |
| dansmith | it is, at least, seemingly spread around a lot | 14:26 |
| fungi | looks like the akanda-appliance and astara-appliance directories also have qcow2 images in them, though those projects are dead now | 14:26 |
| dansmith | it's pretty tough to try to figure out how a job works, using the zuul.o.o/jobs as a map, but having to look all through all the various repos to stitch things together :/ | 14:26 |
| fungi | and yeah, i'm looking for a better example than generic docs jobs | 14:27 |
| dansmith | trove has a guest image publish job | 14:27 |
| dansmith | https://github.com/openstack/trove/blob/master/zuul.d/jobs.yaml#L413 | 14:29 |
| fungi | ah, yeah that's probably a good one. and they've had it working as recently as today: https://tarballs.opendev.org/openstack/trove/images/ | 14:29 |
| dansmith | I don't see how the publish and build jobs are connected though | 14:30 |
| fungi | trove-master-guest-ubuntu-jammy.qcow2 there is from today | 14:30 |
| clarkb | ironic's ipa images are published to static too iirc | 14:30 |
| fungi | yeah, i mentioned ipa a little bit back... magnum and manila are also doing it | 14:30 |
| fungi | i'm just basically running `find /afs/openstack.org/project | 14:31 |
| fungi | /tarballs.opendev.org/openstack/ -type f -name "*.qcow2*"` | 14:31 |
| fungi | on my workstation | 14:31 |
| dansmith | hmm, do they build in check and publish in periodic? | 14:31 |
| fungi | i should probably rerun with -mtime -7 or something | 14:31 |
| fungi | dansmith: some of them may be doing periodic builds instead of from the gate, which is why i'm still hunting | 14:32 |
| fungi | and some are doing it from tags | 14:32 |
| fungi | problem is a lot of these are from back before zuul had artifact handling and so are (re)doing all their building post-merge either from tags or in post pipeline or periodic, because those were the only options at the time and they've never been revisited since there's little interest in changing if they're not broken | 14:36 |
| fungi | so we probably don't have any examples specifically of a promote job publishing artifacts to the tarballs site, all the examples i have are for web content (docs, governance, security...) | 14:39 |
| fungi | in theory they could differ just in the target publication path they specify | 14:40 |
| dansmith | yeah doesn't matter what they're publishing right? | 14:40 |
| fungi | right, if you're looking at https://zuul.opendev.org/t/openstack/builds?project=openstack%2Fossa&skip=0 it's just running openstack-tox-docs in gate which creates an artifact called "Docs archive" that's just a docs-html.tar.gz made by tarring up the contents of docs/build/html, then the promote-security job in the promote pipeline fetches that artifact, extracts it and publishes it | 14:45 |
| fungi | parented on the promote-tox-docs-site-base job (defined in openstack/project-config) but with "publish_site":"security.openstack.org" as an override | 14:45 |
| dansmith | okay I'm not sure how that helps me, unless you're suggesting that I pre-create a directory structure under a fake docs archive that looks like what should be laid out under tarballs/ so that when it gets extracted it goes into the right place? | 14:52 |
| fungi | don't take this as me suggesting anything yet, i'm still thinking through what the options look like and what bits of existing job definitions you'd splice together to get it | 14:54 |
| dansmith | I went down this path thinking it was going to be a relatively easy path to get these into place, but maybe the best thing is to just commit them to the tree and move on? | 14:54 |
| dansmith | okay | 14:54 |
| fungi | i think the promote job for this could specify the afs_tarballs_opendev_org secret but publish_site: "tarballs.opendev.org" and afs_subpath: "{{zuul.project.name}}" | 14:59 |
| fungi | we'd probably also need to set final: true for safety reasons (so other jobs can't parent to it and change the subpath themselves) | 15:02 |
| dansmith | okay and how does the promote job get linked with a gate job so it knows to run? | 15:02 |
| fungi | and could additionally scope it to just the images project with the allowed-projects list | 15:03 |
| fungi | set the download_artifact_job value to the name of the gate job | 15:04 |
| dansmith | oh, I saw that but I didn't think that was the linkage | 15:04 |
| dansmith | fungi: I'm sorry this is so laborious, but.. this went through gate and didn't merge or fail: https://review.opendev.org/c/openstack/os-test-images/+/925114 | 16:09 |
| dansmith | am I missing something else? I'm getting the feeling I should have just put this on my personal github instead of making a huge federal case about it, so please accept my apologies | 16:10 |
| dansmith | ...all I want is to have test images available for verification, but no good deed goes unpunished... | 16:10 |
| clarkb | dansmith: there are no gate jobs defined so it didn't do anything after you approved it (I think that action was a noop) | 16:11 |
| clarkb | dansmith: at the end of the file here: https://review.opendev.org/c/openstack/os-test-images/+/925114/11/.zuul.yaml you need to specify a job or jobs to run in the gate. Can just copy paste the check section and rename check to gate | 16:11 |
| dansmith | so it just needs a gate job and that will make it merge? I would have expected a fail I guess | 16:12 |
| fungi | changes without any jobs for a pipeline don't enqueue anything. this is so that, for example, if you don't have any jobs for the check-arm64 pipeline it doesn't emit a failure for that pipeline when you push a change | 16:13 |
| clarkb | yes it will merge if that job succeeds. You didn't get a failure because there was nothing run to fail. Zuul didn't know it needed to take any action | 16:13 |
| dansmith | okay, but it showed up in the gate queue.. I guess I don't understand the need to just run something in order to have it be merge-able, but will add | 16:15 |
| opendevreview | Merged openstack/project-config master: Remove linaro cloud from Nodepool https://review.opendev.org/c/openstack/project-config/+/925050 | 16:16 |
| dansmith | I guess the first sentence here needs s/test job/test job in the gate queue/ https://docs.opendev.org/opendev/infra-manual/latest/creators.html#add-jobs-for-your-project | 16:17 |
| fungi | dansmith: you can add the literal "noop" job in the gate pipeline if you want it to instantly run a job that does nothing but succeed | 16:18 |
| fungi | it's a built-in job that will just succeed and do nothing | 16:19 |
| clarkb | the underlying reason you need to run a job to merge things is beacuse zuul is the only entity that can merge things. Zuul only merges things when they pass gate tests. | 16:22 |
| dansmith | will templates: noop-jobs get you that for check and gate? | 16:22 |
| clarkb | yes | 16:23 |
| opendevreview | James Page proposed openstack/openstack-zuul-jobs master: openstack-charms: align to Ubuntu Pythons https://review.opendev.org/c/openstack/openstack-zuul-jobs/+/925276 | 16:28 |
| fungi | dansmith: noop-jobs is defined here, for reference: https://opendev.org/openstack/openstack-zuul-jobs/src/branch/master/zuul.d/project-templates.yaml#L18-L31 | 16:43 |
| fungi | you can see it includes the "noop" job i both the check and gate pipelines | 16:43 |
| dansmith | ack, I obviously skipped that part of the doc because I wanted to have _some_ jobs run | 16:44 |
| dansmith | fungi: is this telling me that I'm going to have to define the promote job in project-config because of what you mentioned above about separating credentials from the jobs that do the building? https://review.opendev.org/c/openstack/os-test-images/+/925288 | 17:04 |
| fungi | dansmith: yes, the gate job can be defined in your project but the promote job will need to be in project-config where you see the other promote jobs | 17:37 |
| *** bauzas_ is now known as bauzas | 20:11 | |
| opendevreview | Clark Boylan proposed openstack/project-config master: Remove centos-8-stream image uploads and labels https://review.opendev.org/c/openstack/project-config/+/924790 | 21:02 |
| opendevreview | Clark Boylan proposed openstack/project-config master: Stop building centos 8 stream images https://review.opendev.org/c/openstack/project-config/+/924791 | 21:02 |
| *** bauzas_ is now known as bauzas | 21:14 | |
| opendevreview | Clark Boylan proposed openstack/project-config master: Set OpenDev and Zuul Zuul tenants to use ansible 9 by default https://review.opendev.org/c/openstack/project-config/+/925303 | 21:32 |
| opendevreview | Merged openstack/project-config master: Remove centos-8-stream image uploads and labels https://review.opendev.org/c/openstack/project-config/+/924790 | 21:33 |
| *** bauzas_ is now known as bauzas | 21:55 | |
| opendevreview | Merged openstack/project-config master: Stop building centos 8 stream images https://review.opendev.org/c/openstack/project-config/+/924791 | 22:46 |
| *** bauzas_ is now known as bauzas | 23:07 | |
Generated by irclog2html.py 2.17.3 by Marius Gedminas - find it at https://mg.pov.lt/irclog2html/!