| *** ikhan has joined #zuul | 00:00 | |
| *** tosky has quit IRC | 00:39 | |
| *** wuchunyang has joined #zuul | 00:56 | |
| *** Goneri has quit IRC | 01:12 | |
| *** holser has quit IRC | 01:17 | |
| *** Goneri has joined #zuul | 01:38 | |
| *** zenkuro has quit IRC | 01:50 | |
| *** Goneri has quit IRC | 02:05 | |
| *** bhavikdbavishi has joined #zuul | 02:59 | |
| *** bhavikdbavishi1 has joined #zuul | 03:04 | |
| *** bhavikdbavishi has quit IRC | 03:06 | |
| *** bhavikdbavishi1 is now known as bhavikdbavishi | 03:06 | |
| *** wuchunyang has quit IRC | 04:00 | |
| *** bhavikdbavishi has quit IRC | 04:20 | |
| *** bhavikdbavishi has joined #zuul | 04:21 | |
| *** ikhan has quit IRC | 04:27 | |
| *** ianychoi__ has joined #zuul | 04:57 | |
| *** ianychoi_ has quit IRC | 04:59 | |
| *** saneax has joined #zuul | 05:03 | |
| *** evrardjp has quit IRC | 05:33 | |
| *** evrardjp has joined #zuul | 05:33 | |
| *** jfoufas1 has joined #zuul | 06:03 | |
| *** bhavikdbavishi1 has joined #zuul | 06:09 | |
| *** bhavikdbavishi has quit IRC | 06:10 | |
| *** bhavikdbavishi1 is now known as bhavikdbavishi | 06:10 | |
| *** lyr has joined #zuul | 06:58 | |
| *** bhavikdbavishi has quit IRC | 07:11 | |
| *** mach1na has joined #zuul | 07:13 | |
| *** sanjayu_ has joined #zuul | 07:22 | |
| *** saneax has quit IRC | 07:24 | |
| *** mach1na has quit IRC | 07:41 | |
| *** hashar has joined #zuul | 07:48 | |
| *** mach1na has joined #zuul | 07:54 | |
| *** zenkuro has joined #zuul | 07:58 | |
| *** jcapitao has joined #zuul | 07:59 | |
| *** bhavikdbavishi has joined #zuul | 08:17 | |
| *** bhavikdbavishi1 has joined #zuul | 08:20 | |
| *** bhavikdbavishi has quit IRC | 08:21 | |
| *** bhavikdbavishi1 is now known as bhavikdbavishi | 08:21 | |
| *** zenkuro has quit IRC | 08:35 | |
| *** tosky has joined #zuul | 08:37 | |
| *** jpena|off is now known as jpena | 08:58 | |
| *** wuchunyang has joined #zuul | 09:01 | |
| *** holser has joined #zuul | 09:08 | |
| *** zenkuro has joined #zuul | 09:25 | |
| *** rpittau|afk is now known as rpittau | 09:27 | |
| *** arxcruz|rover is now known as arxcruz|2021 | 09:28 | |
| *** wuchunyang has quit IRC | 09:36 | |
| *** bhavikdbavishi has quit IRC | 09:55 | |
| *** zenkuro has quit IRC | 10:17 | |
| *** zenkuro has joined #zuul | 10:19 | |
| *** bhavikdbavishi has joined #zuul | 10:28 | |
| *** bhavikdbavishi1 has joined #zuul | 10:30 | |
| *** bhavikdbavishi has quit IRC | 10:32 | |
| *** bhavikdbavishi1 is now known as bhavikdbavishi | 10:32 | |
| *** lyr has quit IRC | 10:33 | |
| *** lyr has joined #zuul | 10:34 | |
| *** holser has quit IRC | 10:35 | |
| *** holser has joined #zuul | 10:37 | |
| *** rfolco has joined #zuul | 11:56 | |
| *** mach1na has quit IRC | 12:05 | |
| *** jcapitao is now known as jcapitao_lunch | 12:06 | |
| *** tosky has quit IRC | 12:24 | |
| *** tosky has joined #zuul | 12:25 | |
| *** jpena is now known as jpena|lunch | 12:29 | |
| *** hashar has quit IRC | 12:30 | |
| *** sshnaidm|off is now known as sshnaidm | 12:38 | |
| *** jcapitao_lunch is now known as jcapitao | 12:42 | |
| *** rlandy has joined #zuul | 12:44 | |
| *** hashar has joined #zuul | 12:46 | |
| *** bhavikdbavishi has quit IRC | 12:54 | |
| *** mach1na has joined #zuul | 12:55 | |
| *** zenkuro has quit IRC | 13:26 | |
| *** zenkuro has joined #zuul | 13:26 | |
| *** jpena|lunch is now known as jpena | 13:28 | |
| *** ikhan has joined #zuul | 13:30 | |
| *** zenkuro has quit IRC | 13:33 | |
| *** zenkuro has joined #zuul | 13:34 | |
| openstackgerrit | Tobias Henkel proposed zuul/zuul master: Make reporting asynchronous https://review.opendev.org/c/zuul/zuul/+/691253 | 13:35 |
|---|---|---|
| *** mach1na has quit IRC | 13:58 | |
| avass | I think zuul could benefit from a caching system like githubs action/cache (https://github.com/actions/cache) to store built dependencies | 14:28 |
| avass | something like a zuul_cache module that maybe could somehow have configurable backends | 14:29 |
| *** hashar has quit IRC | 14:51 | |
| *** ajitha has joined #zuul | 14:53 | |
| *** bhavikdbavishi has joined #zuul | 14:54 | |
| *** bhavikdbavishi1 has joined #zuul | 14:56 | |
| *** bhavikdbavishi has quit IRC | 14:58 | |
| *** bhavikdbavishi1 is now known as bhavikdbavishi | 14:58 | |
| tobiash | avass: are you still working on https://review.opendev.org/c/zuul/nodepool/+/735217 (aws image support) or would you be ok if a collegue of mine would continue on that? | 14:59 |
| avass | tobiash: that would be really nice to be honest | 15:03 |
| avass | I probably won't have time to work on it for a while | 15:03 |
| *** jonass has joined #zuul | 15:03 | |
| tobiash | jonass: ^ | 15:03 |
| jonass | great, then i will have a look at it :) | 15:04 |
| avass | jonass: thanks! :) | 15:04 |
| *** Goneri has joined #zuul | 15:17 | |
| ajitha | Hi all, We are maintaining a third party CI for cinder. Recently our CI server migrated to a new environment where all ports are restricted and we can access internet only through proxy. Only port is 22 enough for the communication between review.openstack.org and the zuul server? | 15:24 |
| tobiash | ajitha: theoretically port 22 is enough as long as you don't need to report file comments | 15:25 |
| fungi | ajitha: this is probably more of a question for #opendev or #openstack-infra but the gerrit event stream is served on 29418/tcp not 22/tcp | 15:26 |
| tobiash | ajitha: but I don't know the opendev rules about port 22 | 15:26 |
| tobiash | of course 29418 ;) | 15:26 |
| tobiash | sorry | 15:26 |
| ajitha | ok thank you | 15:26 |
| ajitha | @fungi and tobiash : Thank you | 15:27 |
| *** mach1na has joined #zuul | 15:27 | |
| *** wuchunyang has joined #zuul | 15:51 | |
| *** wuchunyang has quit IRC | 15:56 | |
| zbr | avass: i would personally be very happy to see caching support in gerrit, similar to gh-actions. | 16:07 |
| avass | zbr: yeah I realized it would be nice to have after needing to build nim from source. Now I have the luxury of being able to cache that in the image nodepool uses but that's not always a viable solution :) | 16:14 |
| zbr | avass: i was having pre-commit cache in mind. | 16:15 |
| corvus | i think you're talking about two different caches? | 16:15 |
| corvus | avass: is talking about caching artifacts in zuul and zbr is talking about gerrit? | 16:15 |
| corvus | avass: i agree some general-purpose roles could be useful there | 16:16 |
| avass | corvus, zbr: i thought he ment zuul instead of gerrit | 16:16 |
| zbr | nope: that has nothing to do with gerrit | 16:16 |
| avass | corvus: I'll write up a quick spec for it later, I have some ideas for it | 16:16 |
| zbr | ahh, damn, now i see.. | 16:16 |
| avass | corvus: I was thinking a module if it's possible for it to handle credentials without exposing them to the job | 16:17 |
| zbr | if i remember well avass is not the first to mention caching but i remember that zuul architecture makes caching quite problematic | 16:17 |
| corvus | zbr: i don't understand what caching use case you have in mind. i'm strugglying to reconcile your mentions of "pre- | 16:17 |
| corvus | zbr: i don't understand what caching use case you have in mind. i'm strugglying to reconcile your mentions of "pre-commit" caching and "gerrit" | 16:18 |
| corvus | zbr: maybe you could elaborate | 16:18 |
| zbr | pre-commit tool installs linters inside ~/.cache/pre-commit folder, and they do not change very often. if this folder is caches between builds it would make execution much faster. | 16:19 |
| corvus | zbr: i don't think that zuul's architecture makes caching difficult, on the contrary, i think it makes it quite easy. an ansible role in a trusted playbook can pull or push whatever needs caching. the intermediate registry is an example of this (it's a complicated example, but only because the use-case is complicated) | 16:19 |
| corvus | avass: ^ | 16:19 |
| zbr | the tool knows when to invalidate the cache and even to cleanup old copies, but we need to be able to declare the folder as cached. | 16:20 |
| corvus | (most of the complexity in intermediate registry is due to containers; the actual idea of pulling/pushing in a trusted playbook on the executor to avoid secret exposure is straightforward) | 16:20 |
| zbr | another example is the wheel cache | 16:20 |
| corvus | zbr: 1) those should be quite easy to do in zuul; 2) in *opendev* we have a complicated history with caching and would not necessarily think that heavy caching is desirable. so you may find that is why we aren't already doing them. | 16:21 |
| corvus | so on this subject, make sure you keep the zuul-in-general vs zuul-for-opendev threads distinct :) | 16:22 |
| -openstackstatus- NOTICE: The Gerrit service on review.opendev.org is being restarted quickly to troubleshoot high load and poor query caching performance, downtime should be less than 5 minutes | 16:22 | |
| fungi | zbr: it's not zuul's architecture which makes caching problematic, it's the security concerns around trusting otherwise untrusted inputs to determine what to cache when and when to invalidate that cache | 16:23 |
| corvus | which is why it may make a lot of sense for avass's use case but not opendev's | 16:23 |
| fungi | for example, you can implement a global ccache in zuul, no problem. if untrusted users pollute your ccache with proposed changes which are malicious, they may be able to subvert or block your other builds | 16:24 |
| zbr | my guess is that a "save-cache" should happen on a merge but clearly the cache must be unique per (job-name, repo) | 16:25 |
| fungi | that also assumes the cache maintained by updates on merges from one of your projects isn't used by other projects unless they trust the maintainers of that project | 16:25 |
| avass | I think I'd expect the cache to act for each repo independently at least | 16:28 |
| *** jfoufas1 has quit IRC | 16:29 | |
| *** mach1na has quit IRC | 16:29 | |
| fungi | oh, yep zbr did also say unique by repo (and job name) | 16:32 |
| fungi | that seems reasonably safe. though rather than specifically only on merge, for consistency we'd probably make it so you could set it to only update for post-review pipeline results | 16:32 |
| zbr | yep, any other approach would introduce security issues. | 16:32 |
| avass | fungi: what if you could validate it in a trusted context and update it? | 16:33 |
| fungi | post-review is our convention for builds triggered after the change has a positive maintainer review, even if not yet approved/merged | 16:33 |
| zbr | but we could have variations, like allowing user to define cache keys, but even so the repository should always be implicit part of the key. | 16:33 |
| avass | (somehow) | 16:33 |
| avass | oh wait, update. yeah that makes sense | 16:34 |
| fungi | only let trusted tasks on the executor copy things into the cache rather than relying on job nodes to update the cache directly, we already solve that for all sorts of other build artifacts | 16:35 |
| avass | my idea is something like this: https://etherpad.opendev.org/p/zuul_cache | 16:36 |
| corvus | avass: i think we should look at implementing this first in ansible; i don't think there's a need to do this in zuul itself | 16:36 |
| avass | corvus: I think that would be harder to do since you'd need to delegate credentials to the job | 16:37 |
| fungi | cache contents seem to fit the generic artifact profile anyway | 16:37 |
| avass | or I guess mark something to cache and then cache it in post | 16:37 |
| corvus | avass: right, there are options | 16:38 |
| corvus | avass: job variables could control the behavior | 16:39 |
| avass | I guess it would work similar to upload-artifactory role then, only with variables to choose which backend to use | 16:40 |
| pabelanger | question for zuul-registry, how do I know if the prune command is working? For the last few days, I've been manually running prune, but it doesn't look like anything on filesystem is getting removed. eg: cache is same size and grows each new image upload | 16:46 |
| corvus | pabelanger: i suspect it isn't working; i don't think it's well tested or that we're using it in opendev | 16:48 |
| pabelanger | kk | 16:49 |
| pabelanger | that is what I suspected | 16:49 |
| avass | corvus: updated the pad a bit :) | 16:59 |
| fungi | in opendev we use the swift backend and set expiration on the objects as they're stored, i think? | 17:00 |
| avass | but the backend > executor > node could maybe be simplified | 17:00 |
| *** hashar has joined #zuul | 17:00 | |
| openstackgerrit | Merged zuul/zuul-jobs master: Fix typo with container_images siblings logic https://review.opendev.org/c/zuul/zuul-jobs/+/764230 | 17:01 |
| avass | if was possible to do that with an action plugin instead to give the module a temporary credential it can use to fetch the artifact and then invalidate the credential it would be more effective | 17:02 |
| avass | I think that's why my initial idea was a module | 17:03 |
| *** jcapitao has quit IRC | 17:16 | |
| *** hamalq has joined #zuul | 17:23 | |
| *** rpittau is now known as rpittau|afk | 17:42 | |
| *** hashar is now known as hasharAway | 17:44 | |
| *** jpena is now known as jpena|off | 17:57 | |
| openstackgerrit | Albin Vass proposed zuul/zuul-jobs master: WIP: Zuul Cache role https://review.opendev.org/c/zuul/zuul-jobs/+/764808 | 18:01 |
| openstackgerrit | Albin Vass proposed zuul/zuul-jobs master: WIP: Zuul Cache role https://review.opendev.org/c/zuul/zuul-jobs/+/764808 | 18:03 |
| openstackgerrit | Albin Vass proposed zuul/zuul-jobs master: WIP: Zuul Cache role https://review.opendev.org/c/zuul/zuul-jobs/+/764808 | 18:28 |
| pabelanger | Q: have we considered enabling anonymous access on zuul-registry in opendev? So we can pull images from one zuul system to another? | 18:31 |
| pabelanger | eg: zuul.a.c being able to pull from zuul.o.o registry | 18:32 |
| corvus | pabelanger: do you mean "insecure-ci-registry.opendev.org"? | 18:32 |
| pabelanger | yes. I've been doing some POC using opendev python-builder, and have forked it into zuul.a.c for now | 18:32 |
| corvus | pabelanger: the intermediate registry does allow anonymous access. but i'm not sure what that gets you? | 18:33 |
| corvus | pabelanger: you can fetch images used in check builds... | 18:33 |
| pabelanger | oh, cool. I thought it was disabled | 18:33 |
| corvus | that's the intent -- so you can download a build that failed and test it out | 18:33 |
| corvus | pabelanger: what do you want to do with it? | 18:34 |
| pabelanger | corvus: basically, update opendev:python-builder, then use that in ansible job. | 18:34 |
| corvus | pabelanger: oh, so you want cross-zuul dependencies with artifacts? | 18:35 |
| pabelanger | yah | 18:35 |
| corvus | pabelanger: that won't work currently (the artifact system only works within a single tenant and relies on db access) | 18:35 |
| corvus | pabelanger: but you can kinda-sorta-hacky do it by changing your image to "BASE insecure-ci-registry.opendev.org/...." | 18:36 |
| corvus | obvs you'd have to continually change that as you make new patchsets to a python-builder change | 18:36 |
| pabelanger | Ah, okay. Maybe that is step 1a, see if that works | 18:36 |
| corvus | just never merge a change that depends on insecure-ci-registry.opendev.org. :) | 18:36 |
| corvus | there's a reason we named it that | 18:36 |
| pabelanger | indeed | 18:36 |
| avass | Did we want to have separate caches per job? | 18:38 |
| avass | job+repo canonical name or just canonical name? | 18:39 |
| corvus | avass: seems like repo would be sufficient? | 18:43 |
| openstackgerrit | Albin Vass proposed zuul/zuul-jobs master: WIP: Zuul Cache role https://review.opendev.org/c/zuul/zuul-jobs/+/764808 | 18:44 |
| avass | I think so too | 18:44 |
| avass | I'm gonna see if I can add some tests to that with minio but I think that's pretty solid ^ :) | 18:45 |
| fungi | per repo addresses the security concerns. beyond that, projects can choose to cache per-job data or not i expect, depending on how flexible the implementation is | 18:45 |
| avass | yeah the artifact name is configurable so it could be named something like "{{ zuul.job }}-dep-1.x" | 18:46 |
| fungi | yep, looking at 764808 it's just a matter of making sure your artifacts are named uniquely between your jobs, so not hard | 18:47 |
| fungi | but this also allows a project to share a cache of certain artifacts between jobs too, which could be extremely handy | 18:47 |
| avass | huh I think also makes it a bit easier for jobs if they need to have separate jobs for building and testing | 18:48 |
| avass | you could give it a name like "{{ zuul.build }}-my-package" and then use zuul-cache to pull that in the next job to test it | 18:49 |
| avass | fungi: oh maybe that's what you meant :) | 18:57 |
| fungi | yep, exactly that | 18:58 |
| fungi | or not even so templatey, just remember to choose distinct artifact names in different jobs if you need them to be separate | 18:58 |
| avass | oh but then you might get another changes artifact if you've got a lot of jobs running | 18:59 |
| fungi | could be sufficient to say that builds of different jobs for the same project will reuse commonly-named artifacts among themselves, and that users should set different artifact names in their jobs if they want that | 19:00 |
| *** bhavikdbavishi has quit IRC | 19:05 | |
| openstackgerrit | Merged zuul/zuul master: gerrit: restore change filter when querying https://review.opendev.org/c/zuul/zuul/+/764069 | 19:15 |
| *** tosky has quit IRC | 19:45 | |
| *** wuchunyang has joined #zuul | 19:53 | |
| *** wuchunyang has quit IRC | 19:57 | |
| openstackgerrit | Merged zuul/zuul master: Clarify terms around pause-job documentation https://review.opendev.org/c/zuul/zuul/+/764499 | 20:43 |
| *** tosky has joined #zuul | 20:48 | |
| *** ikhan has quit IRC | 20:49 | |
| *** rfolco has quit IRC | 20:59 | |
| *** ajitha has quit IRC | 22:08 | |
| -openstackstatus- NOTICE: The Gerrit service on review.opendev.org is being restarted quickly to make further query caching and Git garbage collection adjustments, downtime should be less than 5 minutes | 22:38 | |
| *** hasharAway has quit IRC | 22:58 | |
| *** wuchunyang has joined #zuul | 23:55 | |
| *** holser has quit IRC | 23:57 | |
Generated by irclog2html.py 2.17.2 by Marius Gedminas - find it at https://mg.pov.lt/irclog2html/!