| *** bauzas_ is now known as bauzas | 06:58 | |
| *** bauzas_ is now known as bauzas | 08:09 | |
| SvenKieske | mhm, why don't I find the openinfra infra related service announcement mailing list here? https://lists.openstack.org/mailman3/lists/ | 13:08 |
|---|---|---|
| SvenKieske | there was such a thing, wasn't there? | 13:08 |
| frickler | SvenKieske: I think you are looking for https://lists.opendev.org/mailman3/lists/service-discuss.lists.opendev.org/ | 13:11 |
| SvenKieske | yes, ty! too many domains.. | 13:11 |
| fungi | SvenKieske: opendev or openinfra? | 13:11 |
| fungi | openinfra also has its own lists.openinfra.dev | 13:12 |
| fungi | that's where, e.g., the foundation and foundation-board mailing lists are (among others) | 13:12 |
| SvenKieske | no, I was interested in opendev, the distinction is sometimes a little difficult for me :) | 13:13 |
| fungi | makes sense | 13:13 |
| fungi | and yeah, service-announce is the announcement list for opendev, service-discuss is the discussion list | 13:13 |
| SvenKieske | maybe someone can hire a linguist to create an actual list of words and their meaning in openinfra :) (maybe there is already something like this) | 13:14 |
| fungi | well, we try to qualify them when written out... openstack project, openinfra foundation, opendev collaboratory... | 13:17 |
| fungi | but domains are a bit too compact for that | 13:18 |
| SvenKieske | I guess I just wasn't aware there is a distinct openinfra infrastructure which is not the same as the opendev infrastructure, and now it's becoming inconsistent, because following the names there should be openstack infrastructure as well? | 13:20 |
| fungi | what openinfra infrastructure are you asking about? | 13:21 |
| * fungi is now getting confused | 13:22 | |
| fungi | if you mean that the openinfra foundation has a separate domain for its mailing lists, the mailman server we run in the opendev collaboratory is capable of a sort of multi-tenant virtual hosting model, so it serves lists for 7 different domain names at the moment (airshipit.org, katacontainers.io, opendev.org, openinfra.dev, openstack.org, starlingx.io, zuul-ci.org) | 13:26 |
| fungi | each of those can have its own distinct mailing lists, but they're all run on the same server and you can use a single account to access subscription, moderator and list owner functions across all those domains | 13:27 |
| opendevreview | Dan Smith proposed openstack/project-config master: Add promote-test-images job for os-test-images https://review.opendev.org/c/openstack/project-config/+/925401 | 14:15 |
| dansmith | fungi: so I have this up now, which grabs the images tarball as an artifact: https://review.opendev.org/c/openstack/os-test-images/+/925288 | 16:01 |
| dansmith | depends-on a project-config to add the promote thing | 16:01 |
| dansmith | I assume that there's no way to test other than just you eyeball it, merge the config, and then merge this? | 16:02 |
| fungi | thanks! i had already pulled up the promote job change but didn't get time to look it over yet | 16:02 |
| fungi | and yes, we'll have to iterate on it since changes to project-config like this can't run speculatively for obvious security reasons | 16:02 |
| fungi | but maybe we'll get lucky and it works on the first try | 16:02 |
| dansmith | oh, also, | 16:06 |
| dansmith | I just realized that the promote will just copy the tarball there, | 16:06 |
| dansmith | but really we need each image to be curl'able.. so can that untar instead of just copy? | 16:07 |
| dansmith | I guess some docs promote must do that... | 16:07 |
| fungi | i think promote-tox-docs-site-base unpacks the artifact and then uses rsync to copy the file tree into the afs directory relative to the afs_subpath | 16:07 |
| fungi | i can look at the playbook for it in a moment | 16:07 |
| dansmith | I really don't understand all the indirection and why (or where) there are like ten repos of jobs, playbooks and roles | 16:09 |
| dansmith | so it's hard for me to trace where all this stuff is.. the docs upload references a post I haven't found yet | 16:10 |
| dansmith | prepare-docs-for-afs I assume, but... | 16:11 |
| fungi | sorry, meant promote-tox-docs-site-base | 16:11 |
| fungi | anyway, it's defined in the same file. https://zuul.opendev.org/t/openstack/job/promote-tox-docs-site-base also tells you the repo and filename in the "defined at" field | 16:12 |
| fungi | though the playbook is attached to its parent, which is defined in opendev/base-jobs | 16:15 |
| fungi | https://opendev.org/opendev/base-jobs/src/branch/master/zuul.d/jobs.yaml#L362 | 16:16 |
| dansmith | I had just been looking at this: https://github.com/openstack/project-config/blob/master/zuul.d/jobs.yaml#L107 | 16:16 |
| fungi | and here's where that playbook does the extraction: https://opendev.org/opendev/base-jobs/src/branch/master/playbooks/docs/promote.yaml#L22-L30 | 16:16 |
| dansmith | which references a playbook (in this repo) which references a role which is not here or in any of the other repos I have in my tab cache, perhaps because it's in sphinx somewhere | 16:17 |
| dansmith | but I don't see any linkage to hint me as to where to look | 16:17 |
| fungi | yeah, probably the easiest way to trace a job without looking at an actual build result and without resorting to codesearch is to use the zuul jobs browser and follow the parent job link recursively looking at the defined at info | 16:17 |
| dansmith | yeah I've been doing that, but it's just a ton of indirection and easy to get lost | 16:18 |
| fungi | zuul loads configuration from every branch of every repository in a tenant (unless told not to for certain repositories) and maintains a global namespace for all jobs loaded within that tenant | 16:18 |
| fungi | so it basically knows where to find things referred to by other things because it knows where it found everything and tracks that internally | 16:19 |
| dansmith | okay, so my promote will grow a post: that references a playbook, which references a role, which will untar the thing, where, in place in the afs after it has copied the tar there? | 16:20 |
| fungi | that can be convenient because you can move stuff around and not have to manually update linked references, but also bad because it's hard to know where everything is unless you ask zuul | 16:20 |
| fungi | correct, i think. we'll validate that by merging the job, but it's based on how other jobs already work so in theory it should also work as desired | 16:21 |
| fungi | i think the other thing we'll need to do in 925401 is to add that job to the promote pipeline for your project though | 16:21 |
| dansmith | and to be clear, this can all be in project-config right? | 16:22 |
| fungi | dansmith: actually, looks like that last bit i mentioned can be in the os-test-images .zuul.yaml based on https://opendev.org/openstack/contributor-guide/src/branch/master/.zuul.yaml#L10-L12 | 16:23 |
| fungi | so 925401 should be good as-is but maybe another config-core reviewer can also take a look in case i'm missing something obvious | 16:24 |
| dansmith | wait, | 16:24 |
| dansmith | 925401 is not good to go as-is because it only copies the archive tar, | 16:24 |
| dansmith | and my question above about all the roles and playbooks being in project-config is, I hope, going to go in there as well | 16:25 |
| fungi | 925401 should be fine because you're defining a job whose ancestor is opendev-promote-docs-base which has a playbook that does the unpacking and copying | 16:26 |
| dansmith | I'm so confused | 16:26 |
| fungi | at least that's how the other similar jobs are working | 16:27 |
| dansmith | is the parent going to take whatever artifact I collected, regardless of name and filename and untar it in place? | 16:28 |
| fungi | promote-test-images has parent promote-tox-docs-site-base which has parent opendev-promote-docs-base which uses a run playbook that unpacks the artifact and copies the files inside it into afs | 16:28 |
| fungi | yes | 16:29 |
| dansmith | okay, well, whatever you say.. I think I'm too stupid to be playing in this playground, and that I should have just dumped these in a github repo last week as I've spent way too much time trying to make this work (I thought it was going to be much simpler) | 16:31 |
| dansmith | so if you think it's going to work as-is then fine, but it might just be better to cut my losses a this point so I can get on to the actual things I need to do, regardless of where the images end up | 16:31 |
| fungi | if you look at a recent build for the similar job that uses the same parent, like promote-security, you'll see it has a task "extract docs archive": https://zuul.opendev.org/t/openstack/build/bd806fd72e7b433ba0adc75016a65109/console | 16:33 |
| fungi | which it shows coming from the run phase playbook at opendev.org/opendev/base-jobs/playbooks/docs/promote.yaml | 16:34 |
| clarkb | I think the untarring is fine (thats how the zuul artifact to afs tree generally works). But I'm not sure that the parent job you've chosen processes afs_subpath. That var is used by openstack/project-config/playbooks/publish/openstack-afs.yaml which doesn't appear t obe in the tree of that job | 16:37 |
| fungi | clarkb: ah, so we could just hard-code the subpath into the publish_site? looks like that's how https://zuul.opendev.org/t/openstack/job/promote-governance-tc works | 16:44 |
| fungi | "publish_site":"governance.openstack.org/tc" | 16:44 |
| clarkb | ya that is probably the simplest solution | 16:44 |
| fungi | so basically make it publish_site: "tarballs.opendev.org/{{zuul.project.name}}" and drop the afs_subpath | 16:45 |
| fungi | dansmith: i've encapsulated that ^ feedback into an inline review comment on 925401 | 16:48 |
| *** bauzas_ is now known as bauzas | 18:09 | |
| *** bauzas_ is now known as bauzas | 20:04 | |
| opendevreview | Merged 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:30 |
Generated by irclog2html.py 2.17.3 by Marius Gedminas - find it at https://mg.pov.lt/irclog2html/!