*** josefwells has quit IRC | 00:58 | |
*** mgoddard has quit IRC | 01:55 | |
*** ikhan has quit IRC | 02:48 | |
*** ikhan has joined #zuul | 02:48 | |
*** hamalq_ has quit IRC | 02:50 | |
*** ikhan has quit IRC | 02:53 | |
*** bhavikdbavishi has joined #zuul | 03:11 | |
*** bhavikdbavishi has quit IRC | 03:46 | |
*** bhavikdbavishi has joined #zuul | 03:59 | |
*** mgoddard has joined #zuul | 04:12 | |
*** bhavikdbavishi has quit IRC | 04:42 | |
*** wuchunyang has joined #zuul | 04:46 | |
*** bhavikdbavishi has joined #zuul | 04:53 | |
*** mgoddard has quit IRC | 04:53 | |
*** evrardjp has quit IRC | 05:33 | |
*** evrardjp has joined #zuul | 05:33 | |
*** wuchunyang has quit IRC | 05:57 | |
*** bhavikdbavishi has quit IRC | 06:00 | |
*** jfoufas1 has joined #zuul | 06:11 | |
*** mgoddard has joined #zuul | 06:11 | |
*** bhavikdbavishi has joined #zuul | 06:15 | |
openstackgerrit | yatin proposed zuul/zuul-jobs master: Rename CentOS8 repo files to CentOS-Linux https://review.opendev.org/c/zuul/zuul-jobs/+/767668 | 06:43 |
---|---|---|
*** vishalmanchanda has joined #zuul | 06:48 | |
*** mgoddard has quit IRC | 06:53 | |
*** bhavikdbavishi has quit IRC | 06:56 | |
*** piotrowskim has joined #zuul | 07:08 | |
openstackgerrit | Dinesh Garg proposed zuul/zuul-jobs master: Allow customization of pip and helm binary https://review.opendev.org/c/zuul/zuul-jobs/+/767354 | 07:22 |
openstackgerrit | Dinesh Garg proposed zuul/zuul-jobs master: Allow customization of pip and helm charts https://review.opendev.org/c/zuul/zuul-jobs/+/767354 | 07:35 |
*** bhavikdbavishi has joined #zuul | 07:45 | |
zbr|rover | did anyone found a way to force chrome to open build failure links from gerrit in the same tab instead of creating a new one? | 07:46 |
zbr|rover | i tried two extensions so far and none was able to make a simple click open in the same page, even if they were supposed to override the target behavior. | 07:47 |
*** mgoddard has joined #zuul | 08:05 | |
*** jcapitao has joined #zuul | 08:11 | |
*** jpena|off is now known as jpena | 08:17 | |
*** rpittau|afk is now known as rpittau | 08:30 | |
*** hashar has joined #zuul | 08:50 | |
*** mgoddard has quit IRC | 08:53 | |
openstackgerrit | yatin proposed zuul/zuul-jobs master: Rename CentOS8 repo files to CentOS-Linux https://review.opendev.org/c/zuul/zuul-jobs/+/767668 | 08:53 |
*** smyers has quit IRC | 08:56 | |
*** smyers has joined #zuul | 09:00 | |
*** mgoddard has joined #zuul | 09:05 | |
openstackgerrit | Tobias Henkel proposed zuul/nodepool master: Bump openshift dep https://review.opendev.org/c/zuul/nodepool/+/765873 | 09:18 |
*** nils has joined #zuul | 09:24 | |
mhu | felixedel, I'm probably late to ask this, but what was the reason to have different stores depending on contexts (prod, dev, test)? | 09:49 |
mhu | in zuul-webui I mean | 09:49 |
avass | Is anyone caching docker images in dib and has a good solution for that? | 10:07 |
*** bhavikdbavishi has quit IRC | 10:14 | |
openstackgerrit | Clément Mondion proposed zuul/zuul master: [api][cors] Access-Control-Allow-Origin * for all routes https://review.opendev.org/c/zuul/zuul/+/767691 | 10:18 |
openstackgerrit | Tobias Henkel proposed zuul/nodepool master: Bump openshift dep https://review.opendev.org/c/zuul/nodepool/+/765873 | 10:31 |
openstackgerrit | Tobias Henkel proposed zuul/nodepool master: Replace call to deprecated Thread.isAlive https://review.opendev.org/c/zuul/nodepool/+/766757 | 11:20 |
openstackgerrit | Tobias Henkel proposed zuul/nodepool master: Bump openshift dep https://review.opendev.org/c/zuul/nodepool/+/765873 | 11:20 |
*** jcapitao has quit IRC | 11:26 | |
*** hashar is now known as hasharLunch | 11:27 | |
*** bhavikdbavishi has joined #zuul | 11:51 | |
*** bhavikdbavishi has quit IRC | 12:04 | |
openstackgerrit | Tobias Henkel proposed zuul/nodepool master: Bump openshift dep https://review.opendev.org/c/zuul/nodepool/+/765873 | 12:09 |
tobiash | avass: we do, but it's a really ugly hack | 12:11 |
tobiash | avass: it depends, are you using docker or podman? | 12:12 |
tobiash | podman would be much easier | 12:12 |
tobiash | I can try to push up an element for the docker use case as poc | 12:13 |
avass | docker but I'm gonna check if the tools that uses docker can use podman instead | 12:13 |
*** bhavikdbavishi has joined #zuul | 12:13 | |
avass | All I can think of is ugly hacks or importing image archives after boot | 12:13 |
tobiash | avass: I'll decouple that from our environment specific cruft and upload an element to dib | 12:15 |
avass | thanks :) | 12:15 |
avass | it would be nice if docker supported doing things without being completely dependent on it's daemon | 12:16 |
tobiash | for that you need podman ;) | 12:17 |
avass | yeah.... :) | 12:17 |
tobiash | remote: https://review.opendev.org/c/openstack/diskimage-builder/+/767706 POC: Pre-pull docker images | 12:20 |
tobiash | avass: ^ | 12:20 |
tobiash | it depends on pre-installed docker and bwrap into the image | 12:20 |
tobiash | tldr, it runs the into the image installed docker with downstripped options and inside bwrap to do the pulls | 12:21 |
tobiash | it also works within docker btw | 12:21 |
tobiash | so in our deployment it's docker in bwrap in docker | 12:21 |
avass | we're running nodepool-builder in k8s currently but I'm starting to feel like we need to run that outside of the cluster | 12:22 |
*** hasharLunch is now known as hashar | 12:22 | |
tobiash | we as well so that element is targeted to work within k8s | 12:22 |
avass | ah good :) | 12:22 |
tobiash | docs are missing so if you have questions about the vars ask me today :D | 12:23 |
tobiash | it btw also supports authenticated custom registries | 12:24 |
avass | authenticated private registries are exactly what we need :D | 12:24 |
avass | I wanted a pull through cache but that's apparently not supported for private registries | 12:24 |
avass | and we got a way too slow network connection to a registry containing a 6.6Gb image. takes like 10min to just pull that | 12:25 |
tobiash | yeah I know that problem, we at times had 100 parallel jobs that pulled a 12gb image at the same time | 12:27 |
tobiash | you can imagine how that ended | 12:27 |
avass | that's what I'm trying to avoid :) | 12:28 |
avass | probably won't have time to really look at in until after new year. Last day before vacation today. but it's good to know there's a solution at least :) | 12:30 |
*** rfolco has joined #zuul | 12:37 | |
avass | tobiash: so what are the requirements for running that in a kubernetes pod? | 12:51 |
tobiash | avass: the nodepool-builder pod must be privileged | 12:52 |
avass | + MKNOD like we got already I guess | 12:52 |
tobiash | and docker and brap must be installed by different elements | 12:52 |
tobiash | yeah, mknod should be part of privileged I guess | 12:53 |
avass | it wasn't | 12:53 |
*** tosky has joined #zuul | 12:58 | |
*** jpena is now known as jpena|lunch | 13:00 | |
openstackgerrit | Jonas Sticha proposed zuul/nodepool master: WIP: aws: add support for uploading diskimages https://review.opendev.org/c/zuul/nodepool/+/735217 | 13:09 |
*** bhavikdbavishi has quit IRC | 13:16 | |
*** bhavikdbavishi has joined #zuul | 13:17 | |
openstackgerrit | Clément Mondion proposed zuul/zuul master: [api][cors] Access-Control-Allow-Origin * for all routes https://review.opendev.org/c/zuul/zuul/+/767691 | 13:26 |
*** sanjayu_ has quit IRC | 13:29 | |
openstackgerrit | Tobias Henkel proposed zuul/nodepool master: Bump openshift dep https://review.opendev.org/c/zuul/nodepool/+/765873 | 13:34 |
openstackgerrit | Clément Mondion proposed zuul/zuul master: [api][cors] Access-Control-Allow-Origin * for all routes https://review.opendev.org/c/zuul/zuul/+/767691 | 13:39 |
*** bhavikdbavishi has quit IRC | 13:54 | |
avass | tobiash: I think podman actually works so might stick with that. could still be good to have docker as an alternative | 13:55 |
openstackgerrit | Clément Mondion proposed zuul/zuul master: [api][cors] Access-Control-Allow-Origin * for all routes https://review.opendev.org/c/zuul/zuul/+/767691 | 13:59 |
*** jpena|lunch is now known as jpena | 14:00 | |
openstackgerrit | Tobias Henkel proposed zuul/nodepool master: Bump openshift dep https://review.opendev.org/c/zuul/nodepool/+/765873 | 14:02 |
openstackgerrit | Clément Mondion proposed zuul/zuul master: [api][cors] Access-Control-Allow-Origin * for all routes https://review.opendev.org/c/zuul/zuul/+/767691 | 14:11 |
*** bhavikdbavishi has joined #zuul | 14:34 | |
*** iurygregory has joined #zuul | 14:38 | |
openstackgerrit | Tobias Henkel proposed zuul/nodepool master: Bump openshift dep https://review.opendev.org/c/zuul/nodepool/+/765873 | 15:00 |
*** ykarel has joined #zuul | 15:12 | |
openstackgerrit | Matthieu Huin proposed zuul/zuul master: web UI: user login with OpenID Connect https://review.opendev.org/c/zuul/zuul/+/734082 | 15:12 |
icey | is it possible to set the timeout for a cleanup-job? it looks like they just timeout at 15 minutes regardless? | 15:12 |
fungi | ykarel has brought to our attention that centos has reorganized their mirror structure, and the paths hard-coded in the configure-mirrors role no longer work: https://review.opendev.org/767668 | 15:14 |
ykarel | Thanks fungi for raising it here | 15:14 |
fungi | quick review of that would be appreciated | 15:15 |
tobiash | do we need to keep backwards compatibility here? | 15:15 |
fungi | that's a great question. i wonder if there are organizations maintaining centos 8.2 mirrors who won't update them to 8.3 right away | 15:16 |
openstackgerrit | Matthieu Huin proposed zuul/zuul master: Add authentication-realm attribute to tenants https://review.opendev.org/c/zuul/zuul/+/735586 | 15:16 |
ykarel | tobiash, you mean people still using centos8.2 images(and don't run dnf update) instead of centos8.3 images | 15:20 |
ykarel | atleast the nodepool images are updated to 8.3 and have new repo structure | 15:22 |
corvus | icey: do you mean cleanup playbooks? timeout is currently hardcoded to 5 minutes. | 15:31 |
icey | yeah, cleanup playbooks | 15:31 |
icey | corvus: I have a task that I want to run as a cleanup, but it might take a while (10-15 minutes is possible) | 15:32 |
corvus | icey: it should be a straightforward change to zuul to make that configurable | 15:32 |
icey | corvus: it should be OK to put it into a post-run as well, but not quite as reliable, as I understand it? | 15:33 |
icey | ie: won't get run on cancellation? | 15:33 |
corvus | icey: that's right | 15:35 |
zbr|rover | imho 767668 is good to go. | 15:36 |
*** rpittau is now known as rpittau|afk | 15:38 | |
avass | tobiash: wha'ts your podman solution then if I may ask? :) | 15:45 |
tobiash | avass: we don't (yet) use podman ;) | 15:46 |
avass | aww | 15:46 |
avass | maybe I can come up with something then. it should probably be easier to fix than docker | 15:47 |
*** hashar has quit IRC | 15:53 | |
*** jfoufas1 has quit IRC | 16:00 | |
mordred | avass: skopeo should be able to download images and save them locally. I don't know if it can save them in a local docker image cache without a daemon running... but - you could save them in the image in a native oci format, and then run a script on node boot once docker is running to copy the cached images using skopeo from the oci format into the docker image cache. involves a runtime step - but could avoid the need to have the docker daemon running | 16:04 |
mordred | during image build. you could maybe write a systemd unit to do the copy and tag it to run after docker is running | 16:04 |
avass | mordred: yeah that's my backup strategy right now. but since podman seems to be working great with that tool I'm sticking with that for now | 16:05 |
tobiash | mordred, avass: when using docker skopeo is not really an option since it needs the docker daemon as well for docker images (at least a year ago when I looked). However I think using skopeo can be the right choice for caching images for podman since I think the filesystem layout of skopeo and podman are the same | 16:10 |
openstackgerrit | Merged zuul/zuul-operator master: Replace Fedora 31 with Fedora 32 in zuul-operator-functional https://review.opendev.org/c/zuul/zuul-operator/+/767473 | 16:10 |
tobiash | (and copying many images during boot time is probably not really scalable) | 16:11 |
mordred | just get faster disks? :) | 16:11 |
tobiash | it's still preferable to have the images where they should be at boot time :) | 16:11 |
mordred | but yeah - ultimately migrating the workloads to not-docker and using podman and/or crio end-to-end opens up many more flexible doors | 16:12 |
tobiash | especially with the crazy large images | 16:12 |
zbr|rover | is there a way to request an extra role to be installed on a standard job without defining a new one? example: adding ensure-yarn to a tox-linters job for example? | 16:12 |
avass | tobiash: yep exactly that | 16:12 |
zbr|rover | quite often I face the need to add some ensure roles to existing jobs. | 16:12 |
tobiash | zbr|rover: you still can add pre-playbooks in the project-pipeline | 16:13 |
tobiash | zbr|rover: like https://opendev.org/zuul/zuul/src/branch/master/.zuul.yaml#L223 which is just an implicit new job | 16:14 |
zbr|rover | tobiash: i tried adding roles: to it but it does not pick them from there. | 16:14 |
avass | also downloading 30Gb images in a tmpfs was a bad idea | 16:15 |
tobiash | zbr|rover: you need to add a pre-playbook there that calls the role | 16:15 |
zbr|rover | tobiash: that it bit sad as it creates a new file to maintain. | 16:16 |
zbr|rover | maybe we should add a roles variable where you declare which roles to be imported and allow zuul to loop over them. | 16:17 |
corvus | zbr|rover: we made a design decision for zuulv3 that we would not re-implement ansible in zuul; so the execution framework is all playbooks. | 16:18 |
avass | zbr|rover: pre-playbook is sort of how you do that. otherwise you'd just add another way to tell zuul in which step or before which playbook a role should be executed | 16:18 |
tobiash | well you already can do that when you create a pre playbook that does that in your job | 16:18 |
tobiash | there is no need to adapt zuul for this | 16:18 |
corvus | zbr|rover: having said that, if you really wanted to do something like that, you could have a (base?) job with a pre-playbook that included roles based on variables | 16:18 |
corvus | that might be what tobiash is getting at | 16:18 |
tobiash | yes | 16:18 |
zbr|rover | but I want to add role foo to job 1 and role bar to job 2, i would have to create two extra playbooks just for that. | 16:19 |
corvus | personally, i don't think we'd want to structure jobs in zuul-jobs like that though | 16:19 |
corvus | zbr|rover: that's correct | 16:19 |
avass | that could probably lead to nasty errors | 16:20 |
corvus | avass: i agree | 16:20 |
corvus | avass: it could be very confusing for folks because you're building an ansible system on top of ansible | 16:20 |
tobiash | zbr|rover: you could have a pre playbook like this in your base job: http://paste.openstack.org/show/801160/ | 16:20 |
zbr|rover | tobiash: yep, i was already considering it :D | 16:21 |
tobiash | if it's in your base job it would not even have to be part of a zuul-jobs job | 16:21 |
corvus | to further clarify, i don't think we would do this in opendev base jobs either. but if zbr|rover wanted to do something like that for, say, tripleo jobs, that would work. | 16:22 |
corvus | (i just want to be clear about what one *can* do in zuul vs what i think we would be willing to do in specific installations of zuul) | 16:23 |
tobiash | ++ | 16:23 |
zbr|rover | what i was trying to underline is that at this moment zuul does not allow you to alter https://zuul-ci.org/docs/zuul/reference/job_def.html?highlight=job#attr-job.roles when you add the job to your project pipeline. It just ignores the presence of "roles:" under the job name. Other fields can be overriden like voting, vars,... | 16:24 |
tobiash | zbr|rover: roles only adds the roles into the namespace of the job so they can be called from playbooks, are you saying this is not working? | 16:26 |
tobiash | zuul-maint: a review on https://review.opendev.org/c/zuul/nodepool/+/766757 would be appreciated to fix nodepool with python 3.9 | 16:29 |
zbr|rover | tobiash: right... i guess I should end the week, i am starting to get confused. | 16:30 |
openstackgerrit | Merged zuul/zuul-jobs master: Rename CentOS8 repo files to CentOS-Linux https://review.opendev.org/c/zuul/zuul-jobs/+/767668 | 16:31 |
*** hashar has joined #zuul | 16:31 | |
zbr|rover | tobiash: look at https://review.opendev.org/c/zuul/zuul/+/766460/ and its dependency. | 16:32 |
fungi | do we know why nodepool-functional-openstack-src is taking so long to run? | 16:33 |
zbr|rover | mainly i need to assure that zuul-tox-docs has yarn installed, so I added it to the job definition and forgot to call it. | 16:33 |
*** jfoufas1 has joined #zuul | 16:33 | |
tobiash | zbr|rover: adding the role is not needed there since it's part of zuul-jobs which is already added in a parent job. Instead just add a pre playbook that calls this role. | 16:36 |
tobiash | fungi: I don't know, but likely unrelated | 16:37 |
openstackgerrit | Sorin Sbârnea proposed zuul/project-config master: Add yarn to zuul-tox-docs https://review.opendev.org/c/zuul/project-config/+/767122 | 16:37 |
tobiash | fungi: typically it's much faster so might be a slow node or problems in the mirror infrastructure | 16:38 |
fungi | tobiash: maybe. it ran quickly two days ago, but twice in a row today it timed out | 16:39 |
openstackgerrit | Sorin Sbârnea proposed zuul/zuul master: Document tox environments https://review.opendev.org/c/zuul/zuul/+/766460 | 16:40 |
fungi | tobiash: could just be coincidence, but i'll see if i can spot any commonality between the two builds | 16:40 |
tobiash | fungi: where is the second? I see only one timeout in the recent builds: https://zuul.opendev.org/t/zuul/builds?job_name=nodepool-functional-openstack-src&project=zuul/nodepool | 16:40 |
fungi | tobiash: oh! you're right, the previous one was nodepool-functional-openstack | 16:41 |
fungi | not -src | 16:41 |
tobiash | right, so two functional openstack: https://zuul.opendev.org/t/zuul/builds?job_name=nodepool-functional-openstack-src&job_name=nodepool-functional-openstack | 16:42 |
tobiash | probably regardless of src or not | 16:42 |
fungi | i agree, likely whatever's slow in some environments is the same in both versions of the job | 16:42 |
tobiash | fungi: there is a huge difference in devstack setup | 16:44 |
tobiash | http://paste.openstack.org/show/801161/ | 16:45 |
tobiash | fast one vs timeouted | 16:45 |
tobiash | so setting up devstack took more than an hour | 16:45 |
tobiash | apt-get was ten times slower | 16:46 |
*** piotrowskim has quit IRC | 16:46 | |
tobiash | both timeouts were in vexxhost-ca-ymq-1 | 16:48 |
zbr|rover | corvus: let me guess: yarn is not installed as being in protected repo? so we cannot test the change. | 16:54 |
corvus | zbr|rover: correct | 16:54 |
zbr|rover | https://ea507024840f9c0decff-897daedd12d6711e791474c4dbb73e9e.ssl.cf1.rackcdn.com/766460/10/check/zuul-tox-docs/fec4ea3/job-output.txt failed without any attempt to run ensure-yarn | 16:54 |
corvus | zbr|rover: you may want to override that in just the zuul repo | 16:54 |
corvus | it's a more targeted change anyway, since no other docs job needs it | 16:55 |
zbr|rover | sadly buntu does not have yarn right available, so bindep cannot save me. | 16:56 |
corvus | i'm comfortable either way though. i +2d 767122 with comment. | 16:56 |
*** rlandy has joined #zuul | 16:58 | |
openstackgerrit | Sorin Sbârnea proposed zuul/zuul master: Document tox environments https://review.opendev.org/c/zuul/zuul/+/766460 | 17:01 |
fungi | i can see both sides of it. it's nice to have a consistent docs job across the zuul projects, but unless we expect nodepool or zuul-client et cetera to have javascript content at some point it's a bit of additional bloat in their docs builds to install a tool which won't be run | 17:02 |
zbr|rover | i wonder how big are the images used by github actions, as they took a very different path than us: try to fit most build tools on images, which make me believe they are quite fat. | 17:04 |
zbr|rover | but they avoid having a "pre" stage that is compute and network intensive. | 17:05 |
corvus | zbr|rover: (us==opendev in that, not zuul). | 17:05 |
corvus | zbr|rover: but yes, opendev used to have fat images, then decided to take a different path and has moved to [mostly] slim images. | 17:06 |
zbr|rover | corvus: and we know which approach is better? | 17:06 |
corvus | zbr|rover: no right answer generally, but so far, i think in opendev's case the slim images have been an improvement for that environment. | 17:07 |
zbr|rover | clearly for system testing we cannot use fat images. but for unittesting | 17:07 |
*** jpena is now known as jpena|off | 17:16 | |
*** hamalq has joined #zuul | 17:19 | |
*** vishalmanchanda has quit IRC | 17:19 | |
zbr|rover | corvus: apparenly installing yarn does not install it in PATH, https://6f670868c142d4e8c5b3-0595cf8ce23c3a62b4c5e95f9113455a.ssl.cf5.rackcdn.com/766460/11/check/zuul-tox-docs/9f85aa8/job-output.txt | 17:20 |
*** hamalq_ has joined #zuul | 17:21 | |
zbr|rover | bit weird as the task uses default path, but the tox job fails to find it. | 17:22 |
zbr|rover | maybe PATH is not passed in tox.ini... | 17:22 |
openstackgerrit | Sorin Sbârnea proposed zuul/zuul master: Document tox environments https://review.opendev.org/c/zuul/zuul/+/766460 | 17:24 |
*** hamalq has quit IRC | 17:24 | |
zbr|rover | what is weird is why i was able to run it locally w/o having to edit PATH | 17:25 |
tristanC | zbr|rover: we do use container images with the tool pre-installed, effectively skipping zuul-jobs pre phase | 17:30 |
openstackgerrit | Matthieu Huin proposed zuul/zuul master: web UI: allow a privileged user to dequeue a change https://review.opendev.org/c/zuul/zuul/+/734850 | 17:31 |
tristanC | even using a curated node_modules bundle to enable javascript zuul jobs to run under 2 minutes | 17:33 |
corvus | and that's why all the ensure- zuul-jobs roles are designed to skip their work if tools are pre-installed | 17:33 |
tristanC | corvus: that's not the case for yarn at least, it uses `state: latests` | 17:37 |
tristanC | and also install repositories unconditionnaly | 17:37 |
corvus | that's a bug; that's how they're supposed to work | 17:38 |
corvus | that's why we named them 'ensure' vs 'install' | 17:39 |
openstackgerrit | Merged zuul/nodepool master: Replace call to deprecated Thread.isAlive https://review.opendev.org/c/zuul/nodepool/+/766757 | 17:40 |
zbr|rover | corvus: still broken, i don't know why and i need to leave. feel free to look, if you have time. | 17:48 |
*** jfoufas1 has quit IRC | 17:48 | |
zbr|rover | sphinx output is not very useful here | 17:48 |
*** bhavikdbavishi has quit IRC | 18:01 | |
*** ykarel has quit IRC | 18:28 | |
pabelanger | I'd appreciate if I could get a +A on https://review.opendev.org/c/zuul/zuul-jobs/+/767361 | 18:29 |
pabelanger | for a friday review | 18:30 |
*** hashar is now known as hasharDinner | 18:31 | |
pabelanger | avass: tobiash: so, I'm going to be playing with podman cache more over the break. On of our teams, doesn't like we rebuild all the layers each time a new PR is done. This is bascially podman build . --no-cache. So, I want to see, if there is a way we can share the cache, between PRs when possible for this project. I'm un sure if podman pull foo.bar is more then enough, to then do podman build . | 18:31 |
pabelanger | -t foo.bar and the cache used, if nothing changed | 18:31 |
pabelanger | avass: tobiash: right now, this team is using static nodes, and I want to get them off that. But speed of builds is the block right now | 18:32 |
*** armstrongs has joined #zuul | 18:32 | |
openstackgerrit | Merged zuul/zuul-jobs master: Create tox_package_name for tox role https://review.opendev.org/c/zuul/zuul-jobs/+/767361 | 18:47 |
avass | pabelanger: maybe https://review.opendev.org/c/zuul/zuul-jobs/+/764808 is a good fit for that | 18:50 |
avass | that way you don't rebuild all the layers but you need to download/upload them all the time | 18:51 |
pabelanger | avass: ah, neat. That could just work | 18:51 |
*** hasharDinner is now known as hashar | 19:02 | |
avass | pabelanger: maybe it could be optimized to work with image layers efficiently somehow. because if you just cache, say: .local/share/containers/storage/overlay-images/ that could easily grow over time | 19:18 |
openstackgerrit | Matthieu Huin proposed zuul/zuul master: web UI: user login with OpenID Connect https://review.opendev.org/c/zuul/zuul/+/734082 | 19:18 |
openstackgerrit | Matthieu Huin proposed zuul/zuul master: Add authentication-realm attribute to tenants https://review.opendev.org/c/zuul/zuul/+/735586 | 19:18 |
avass | and then it wouldn't be very efficient anymore | 19:19 |
openstackgerrit | Matthieu Huin proposed zuul/zuul master: web UI: allow a privileged user to dequeue a change https://review.opendev.org/c/zuul/zuul/+/734850 | 19:25 |
*** armstrongs has joined #zuul | 19:33 | |
armstrongs | Hey with override-checkout option is there an option to configure a fork? | 19:34 |
armstrongs | Looking to do this on required-projects if possible | 19:34 |
fungi | armstrongs: you'll have to be more specific about what you mean by "configure a fork" | 19:37 |
fungi | if you mean checkout a different project in place of a listed required project, i don't think so. you'd need to add the fork to the projects in the zuul tenant and then reference it explicitly in an altered required-projects list | 19:38 |
avass | yeah the fork is technically a completely different repo isn't it? | 19:41 |
avass | so that would be a different remote with the same content and override-checkout only handles refs | 19:42 |
*** armstrongs has quit IRC | 19:47 | |
*** rlandy has quit IRC | 20:14 | |
*** rfolco has quit IRC | 20:40 | |
*** rfolco has joined #zuul | 20:40 | |
*** _erlon_ has quit IRC | 20:49 | |
*** nils has quit IRC | 21:30 | |
*** zenkuro has joined #zuul | 21:43 | |
*** bodgix has left #zuul | 22:08 | |
*** sduthil has quit IRC | 22:16 | |
*** hashar has quit IRC | 22:45 | |
*** dmsimard5 has joined #zuul | 23:50 | |
*** dmsimard has quit IRC | 23:52 | |
*** dmsimard5 is now known as dmsimard | 23:52 |
Generated by irclog2html.py 2.17.2 by Marius Gedminas - find it at https://mg.pov.lt/irclog2html/!