| -@gerrit:opendev.org- Ian Wienand proposed: | 00:03 | |
| - [zuul/zuul] 832486: zuul/web: Ensure API calls reject unkonwn methods https://review.opendev.org/c/zuul/zuul/+/832486 | ||
| - [zuul/zuul] 832505: zuul/web : Make /project end-point reject PUT https://review.opendev.org/c/zuul/zuul/+/832505 | ||
| - [zuul/zuul] 832731: zuul/web : move method checking into common decorator https://review.opendev.org/c/zuul/zuul/+/832731 | ||
| -@gerrit:opendev.org- Ian Wienand proposed: | 00:34 | |
| - [zuul/zuul] 832731: zuul/web : move method checking into common decorator https://review.opendev.org/c/zuul/zuul/+/832731 | ||
| - [zuul/zuul] 832733: zuu/web : add CORS and method handler for static files https://review.opendev.org/c/zuul/zuul/+/832733 | ||
| -@gerrit:opendev.org- Ian Wienand proposed: | 01:23 | |
| - [zuul/zuul] 832731: zuul/web : move method checking into common decorator https://review.opendev.org/c/zuul/zuul/+/832731 | ||
| - [zuul/zuul] 832733: zuu/web : add CORS and method handler for static files https://review.opendev.org/c/zuul/zuul/+/832733 | ||
| -@gerrit:opendev.org- Ian Wienand proposed: [zuul/zuul] 832733: zuul/web : add CORS and method handler for static files https://review.opendev.org/c/zuul/zuul/+/832733 | 01:23 | |
| @iwienand:matrix.org | $ react-scripts build | 02:14 |
|---|---|---|
| @iwienand:matrix.org | ATAL ERROR: MarkCompactCollector: young object promotion failed Allocation failed - JavaScript heap out of memory | 02:14 |
| @iwienand:matrix.org | https://storage.bhs.cloud.ovh.net/v1/AUTH_dcaab5e32b234d56b626f72581e3644c/zuul_opendev_logs_ff3/832486/5/check/zuul-build-image/ff38a40/job-output.txt | 02:15 |
| @iwienand:matrix.org | first time i've seen this | 02:15 |
| -@gerrit:opendev.org- James E. Blair https://matrix.to/#/@jim:acmegating.com proposed: | 03:15 | |
| - [zuul/zuul] 832362: Report per-branch cyclic-dependency conflicts https://review.opendev.org/c/zuul/zuul/+/832362 | ||
| - [zuul/zuul] 832363: Add queue.dependencies-by-topic https://review.opendev.org/c/zuul/zuul/+/832363 | ||
| -@gerrit:opendev.org- Simon Westphahl proposed: [zuul/zuul] 832517: Include original path of renamed file for a PR https://review.opendev.org/c/zuul/zuul/+/832517 | 07:14 | |
| -@gerrit:opendev.org- Simon Westphahl proposed: [zuul/zuul] 832517: Include original path of renamed file for a PR https://review.opendev.org/c/zuul/zuul/+/832517 | 07:20 | |
| @westphahl:matrix.org | corvus: ^ something like this? | 07:21 |
| -@gerrit:opendev.org- Dong Zhang proposed: [zuul/zuul] 832757: debug test for bundle id https://review.opendev.org/c/zuul/zuul/+/832757 | 07:48 | |
| -@gerrit:opendev.org- Dong Zhang proposed: [zuul/zuul] 832757: debug test for bundle id https://review.opendev.org/c/zuul/zuul/+/832757 | 08:08 | |
| -@gerrit:opendev.org- Dong Zhang proposed: [zuul/zuul] 832757: debug test for bundle id https://review.opendev.org/c/zuul/zuul/+/832757 | 08:40 | |
| -@gerrit:opendev.org- Dong Zhang proposed: [zuul/zuul] 832757: debug test for bundle id https://review.opendev.org/c/zuul/zuul/+/832757 | 09:31 | |
| -@gerrit:opendev.org- Dong Zhang proposed: [zuul/zuul] 832757: debug test for bundle id https://review.opendev.org/c/zuul/zuul/+/832757 | 09:52 | |
| -@gerrit:opendev.org- Dong Zhang proposed: [zuul/zuul] 832757: debug test for bundle id https://review.opendev.org/c/zuul/zuul/+/832757 | 10:37 | |
| -@gerrit:opendev.org- Dong Zhang proposed: [zuul/zuul] 831925: Inject bundle id to inventroy zuul.items https://review.opendev.org/c/zuul/zuul/+/831925 | 11:25 | |
| -@gerrit:opendev.org- yatin proposed: [zuul/zuul-jobs] 832497: [multi-node-bridge] Allow to skip openvswitch installation https://review.opendev.org/c/zuul/zuul-jobs/+/832497 | 12:59 | |
| @fungicide:matrix.org | sean-k-mooney: to be clear, there are lots of ways you can install zuul, we prefer to thoroughly document one way because we discovered that if we try to maintain documentaiton for multiple install methods then they get out of sync and some get neglected. the quickstart/docker-compose we document is one we also test on every change, so we can be sure it works reliably and consistently | 13:14 |
| @sean-k-mooney:matrix.org | ack i have deployed zuul many times in the past | 13:15 |
| @sean-k-mooney:matrix.org | i rebuilt the vm with debian 11 and installed docker and ran though the example config last night | 13:16 |
| @sean-k-mooney:matrix.org | podman and docker has a slight delta in behavior so podman-compose does not result in the service name being a resolveable hostname | 13:18 |
| @sean-k-mooney:matrix.org | its a bug that podman-compose should fix | 13:18 |
| @fungicide:matrix.org | ahh, got it. that's good to keep in mind, thanks | 13:19 |
| @sean-k-mooney:matrix.org | so ya once i created a docker account to bypass the pull limit and change to a disto that can install docker it was quick to deploy | 13:19 |
| @sean-k-mooney:matrix.org | im debating if im going to try the zuul operator later. there was no good way to deploy k8s on centos9stream but with debian i can now just use kubeadm | 13:21 |
| @sean-k-mooney:matrix.org | compose will do for now however | 13:21 |
| @tristanc_:matrix.org | sean-k-mooney: software-factory also provides ready to use rpm package for zuul and nodepool you can deploy on CentOS in a few minutes: https://docs.softwarefactory-project.io/sf-config-3.6/operator/quickstart.html | 13:27 |
| @sean-k-mooney:matrix.org | yes im aware but i dont like the extra layers of indreiction it adds | 13:28 |
| @sean-k-mooney:matrix.org | basically if im deploying zuul i want to have a vanilla zuul | 13:28 |
| @sean-k-mooney:matrix.org | i dont think software factory support centos 9 stream by the way | 13:28 |
| @sean-k-mooney:matrix.org | i did look quickly at it before i started installing zuul | 13:28 |
| @tristanc_:matrix.org | sean-k-mooney: what do you mean by a vanilla zuul? | 13:29 |
| @sean-k-mooney:matrix.org | upstream without the extra layers of using sfconfig | 13:31 |
| @tristanc_:matrix.org | sean-k-mooney: the zuul package is built using upstream source, sfconfig mostly takes care of setting up tls and initializing the project config repo with logserver secrets. | 13:33 |
| @sean-k-mooney:matrix.org | so i dont need to use sfconfig | 13:34 |
| @sean-k-mooney:matrix.org | and it has centos 9 stream packages | 13:34 |
| @sean-k-mooney:matrix.org | i have alredy reinstalled at thsi point so there is not really any benifit in reinstalling centos 9 again at least right now | 13:35 |
| @tristanc_:matrix.org | sean-k-mooney: well if you would like to setup the logserver and configuring the pipeline and base job by hand you can, but having sfconfig setup the full service can be a time saver, especially if you want to see the job running quickly. | 13:37 |
| @tristanc_:matrix.org | anyway, we are about to release version 3.7 which will use podman to start the services, then we'll be able to support any distro which has podman and ansible. | 13:38 |
| -@gerrit:opendev.org- Matthieu Huin https://matrix.to/#/@mhuin:matrix.org proposed on behalf of Tobias Henkel: [zuul/zuul] 772695: Perform per tenant locking in getStatus https://review.opendev.org/c/zuul/zuul/+/772695 | 13:54 | |
| -@gerrit:opendev.org- Matthieu Huin https://matrix.to/#/@mhuin:matrix.org proposed: [zuul/zuul] 832293: REST API: cache tenants list https://review.opendev.org/c/zuul/zuul/+/832293 | 13:54 | |
| @gobi_g:matrix.org | Can we set multiple tenant for each branch of a repository? If yes could you please the reference | 14:58 |
| @avass:vassast.org | sean-k-mooney: there's also k3s if you just want a small kubernetes deployment | 15:08 |
| @avass:vassast.org | It removes etcd and uses SQLite instead | 15:09 |
| @gobi_g:matrix.org | > <@gobi_g:matrix.org> Can we set multiple tenant for each branch of a repository? If yes could you please the reference | 15:14 |
| I don't want to run development branch and production branch tests in single tenant. | ||
| @gobi_g:matrix.org | Can I know where I can find the project.yaml file for https://zuul.opendev.org/t/zuul/status this tenant? | 15:35 |
| @clarkb:matrix.org | karthi: https://opendev.org/openstack/project-config/src/branch/master/zuul/main.yaml#L1602-L1675 is that what yo uare looking for? | 15:37 |
| @gobi_g:matrix.org | Thanks Clark: Also I want to know how to setup tenants for same repository respect to branch | 15:42 |
| @clarkb:matrix.org | karthi: I don't think that is a thing? if you put the project in two different tenants both tenants will see all the branches | 15:44 |
| @gobi_g:matrix.org | How to trigger pipeline only in specific tenant? | 15:47 |
| @gobi_g:matrix.org | Is there any config to specify in tenant to only watch on specific branch or we have to specify it in job only? | 15:48 |
| @clarkb:matrix.org | I think you may have to do that by defining the job to only run against specific branches. However, both tenants may try to run the job? Others here may have better ideas | 15:49 |
| @gobi_g:matrix.org | How to specify the job to run on specific branch? Using job m.branches parameter or something else? Clark: | 15:51 |
| @clarkb:matrix.org | karthi: usually the best way to do that is to only define the job on the branch you want it. So in branch foo's zuul.yaml include it but don't include it in branch bar's zuul.yaml | 15:52 |
| @clarkb:matrix.org | using the branches parameter gets complicated if you define the use of a branch from another branch and should generally be avoided | 15:52 |
| @avass:vassast.org | Clark: karthi i guess you could have two different load paths for the tenants, but it sounds complicated to use the same project in two tenants | 15:54 |
| @avass:vassast.org | So zuul-<tenant>.d for each tenant | 15:54 |
| @gobi_g:matrix.org | Albin Vass: so is it good to run both dev and production tests in same server? | 15:55 |
| @avass:vassast.org | Yeah, i mean i don't know your usecase so i don't understand why you need to put it in two different tenants | 15:57 |
| @gobi_g:matrix.org | I want to separate the tests for each branch. | 15:59 |
| 1) split it into two different tenants | ||
| 2) run it in 2 different zuul servers (so any hardware failure in dev won't affect prod tests) | ||
| @gobi_g:matrix.org | I'm discussing about option 1 | 15:59 |
| @gobi_g:matrix.org | > <@clarkb:matrix.org> karthi: usually the best way to do that is to only define the job on the branch you want it. So in branch foo's zuul.yaml include it but don't include it in branch bar's zuul.yaml | 16:01 |
| Clark: The jobs needs to be in both tenants but trigger only on specific branch | ||
| @avass:vassast.org | The easy way to dev and prod config would probably be to use: | 16:01 |
| https://zuul-ci.org/docs/zuul/latest/tenants.html#attr-tenant.untrusted-projects.%3Cproject%3E.extra-config-paths | ||
| @gobi_g:matrix.org | I couldn't see the option here Albin Vass: | 16:03 |
| -@gerrit:opendev.org- Matthieu Huin https://matrix.to/#/@mhuin:matrix.org proposed: [zuul/zuul] 832293: REST API: cache tenants list https://review.opendev.org/c/zuul/zuul/+/832293 | 16:53 | |
| @fungicide:matrix.org | > <@gobi_g:matrix.org> Albin Vass: so is it good to run both dev and production tests in same server? | 17:23 |
| i think you may be confused about zuul's architecture. zuul is a job scheduler. one zul scheduler can schedule jobs to hundreds or thousands of different test servers | ||
| @fungicide:matrix.org | > <@gobi_g:matrix.org> Albin Vass: so is it good to run both dev and production tests in same server? | 17:23 |
| * i think you may be confused about zuul's architecture. zuul is a job scheduler. one zuul scheduler can schedule jobs to hundreds or thousands of different test servers | ||
| @fungicide:matrix.org | the zuul scheduler can run different jobs for different branches of a single project from within one tenant | 17:24 |
| @fungicide:matrix.org | you don't need to use separate tenants in order to run tests on separate servers for different branches | 17:25 |
| @fungicide:matrix.org | by default, changes for different branches of the same project share a queue in dependent pipelines, but there is an option to make dependent pipeline queues branch-specific if that's your preference | 17:26 |
| @andrebeltrami:matrix.org | Hi guys, it's possible to get the node-id from nodepool in devstack playbooks? Is there any documentation about it? | 18:24 |
| @clarkb:matrix.org | andrebeltrami: it's in the hostname on OpenDev. And we log that in the inventory | 18:29 |
| @andrebeltrami:matrix.org | oh thanks Clark, I'll take a look... | 18:30 |
| -@gerrit:opendev.org- Zuul merged on behalf of James E. Blair https://matrix.to/#/@jim:acmegating.com: [zuul/zuul] 832384: Add Felix to Zuul Maintainers https://review.opendev.org/c/zuul/zuul/+/832384 | 18:41 | |
| @gobi_g:matrix.org | > <@fungicide:matrix.org> by default, changes for different branches of the same project share a queue in dependent pipelines, but there is an option to make dependent pipeline queues branch-specific if that's your preference | 19:29 |
| fungi: could you please share any reference? | ||
| @gobi_g:matrix.org | * fungi: could you please share any reference for how to setup? | 19:29 |
| @fungicide:matrix.org | > <@gobi_g:matrix.org> fungi: could you please share any reference for how to setup? | 19:52 |
| the option for branch-specific queues is here: https://zuul-ci.org/docs/zuul/latest/config/queue.html#attr-queue.per-branch | ||
| @fungicide:matrix.org | for more general configuration examples, https://zuul-ci.org/docs/zuul/latest/howtos/pti.html and https://zuul-ci.org/docs/zuul/latest/tutorials/quick-start.html#configure-zuul-pipelines are good, but you're not likely to find an example of exactly the setup you're describing. if you can't work it out from the documentation and discussing with us, there are also companies you can pay for support/assistance here: https://zuul-ci.org/start | 19:56 |
| @gobi_g:matrix.org | Okay. Let's say I configured 2 servers one is for dev and another for production. | 20:00 |
| Now created a MR in dev branch means how it will trigger job only in zuul dev server? | ||
| @fungicide:matrix.org | when you say "configured two servers" you mean two static test nodes on which your jobs should run? | 20:10 |
| @fungicide:matrix.org | zuul consists of lots of services (scheduler, web, executor, merger, finger gateway, node launcher, node builder...) | 20:11 |
| @gobi_g:matrix.org | No. Two different zuul server nodes. Each one contains it's own (scheduler, web, executor, .. etc) | 20:12 |
| @fungicide:matrix.org | those can all run on different servers if you want, and you can run more than one of each and they'll pool their workloads | 20:12 |
| @fungicide:matrix.org | but then they can also run their jobs on separate "nodes" where your tests would probably happen | 20:12 |
| @fungicide:matrix.org | > <@gobi_g:matrix.org> No. Two different zuul server nodes. Each one contains it's own (scheduler, web, executor, .. etc) | 20:14 |
| i still don't understand why. that's not how zuul is designed to operate. it's got multiple layers of isolation built in already so you shouldn't need independent zuul deployments to separate things | ||
| @gobi_g:matrix.org | Yes. That is correct. It's for avoiding hardware in one (dev) don't affect another (prod). | 20:14 |
| @gobi_g:matrix.org | Hardware Failure* | 20:15 |
| @fungicide:matrix.org | you'd probably benefit from (re)reading the zuul documentation, starting with the fundamental descriptions of its design and operation | 20:16 |
| @fungicide:matrix.org | zuul is already designed for highly-available operation, so failure of zuul servers is handled | 20:17 |
| @fungicide:matrix.org | * zuul is already designed for highly-available operation, so failure of zuul servers is handled automatically | 20:18 |
| @gobi_g:matrix.org | fungi: okay. Can you say whether this setup achievable or not? | 20:24 |
| Application repository: | ||
| Dev-branch | ||
| Master-branch | ||
| Zuul-config repository: | ||
| Dev-branch (config for zuul server 1) | ||
| Master-branch (config for zuul server 1) | ||
| In my knowledge, if any commit added in application repository dev-branch it will trigger pipeline in both servers 1&2 unless we specify the different labels in zuul-config project pipeline file. | ||
| I want to know is there a way to restrict job trigger, with respect to the zuul server without labels? | ||
| @gobi_g:matrix.org | * fungi: okay. Can you say whether this setup achievable or not? | 20:25 |
| Application repository: | ||
| Dev-branch | ||
| Master-branch | ||
| Zuul-config repository: | ||
| Dev-branch (config for zuul server 1) | ||
| Master-branch (config for zuul server 2) | ||
| In my knowledge, if any commit added in application repository dev-branch it will trigger pipeline in both servers 1&2 unless we specify the different labels in zuul-config project pipeline file. | ||
| I want to know is there a way to restrict job trigger, with respect to the zuul server without labels? | ||
| @fungicide:matrix.org | i don't know if what you describe is possible, you could probably do it that way but that's not how zuul is designed to be used. if what you want is to isolate builds and job definitions for application repository dev-branch from application repository master-branch, the easiest solution is to have branch-specific job configuration and use different test nodes to run those jobs | 20:29 |
| @fungicide:matrix.org | you don't need multiple zuul deployments or even separate tenants to accomplish that | 20:29 |
| @fungicide:matrix.org | it seems like you're unnecessarily complicating the design of your deployment based on incorrect assumptions about zuul's capabilities | 20:30 |
| @gobi_g:matrix.org | fungi: got it. One last request. Could please share reference for that branch specific job configuration? | 20:32 |
| -@gerrit:opendev.org- Zuul merged on behalf of James E. Blair https://matrix.to/#/@jim:acmegating.com: [zuul/zuul] 832388: Add Simon to Zuul Maintainers https://review.opendev.org/c/zuul/zuul/+/832388 | 20:33 | |
| @fungicide:matrix.org | > <@gobi_g:matrix.org> fungi: got it. One last request. Could please share reference for that branch specific job configuration? | 20:37 |
| there are two ways to do branch-specific jobs.. one is implicit branch matching, basically adding jobs in the project configuration on branches where you want them to run (this is most common with in-project configuration). the other way is explicit branch matchers, ``branch`` arguments in the job definitions or variants (most common when the jobs are defined in a different repository than the one for which they're being run, e.g. a trusted config project) | ||
| @gobi_g:matrix.org | fungi: thanks for all the details | 20:39 |
| @fungicide:matrix.org | i'm working on getting you links but my browser is crawling so give me a minute (i'm on a videoconference call for work right now too) | 20:41 |
| -@gerrit:opendev.org- James E. Blair https://matrix.to/#/@jim:acmegating.com proposed: [zuul/zuul] 832391: Remove inactive maintainers https://review.opendev.org/c/zuul/zuul/+/832391 | 20:41 | |
| @gobi_g:matrix.org | fungi: that would be a great help. Thanks | 20:42 |
| @fungicide:matrix.org | karthi: https://zuul-ci.org/docs/zuul/latest/config/job.html#attr-job.branches | 20:42 |
| @fungicide:matrix.org | the second paragraph of https://zuul-ci.org/docs/zuul/latest/config/project.html talks about implicit branch matching as an alternative method | 20:47 |
| @y2kenny:matrix.org | Are there anything in either executor.git_dir or merger.git_dir that is unique to the executor or merger? I am trying to get around the problem of cold starting executor or merger. With Zuul running for awhile, things are responding in a timely way. But if I want to scale Zuul up by adding additional executor or merger, their git_dir would be empty initially so any jobs assigned to the cold executor/merger will take quite a bit longer (depending on the size of the repos.) Would there be a problem if I "pre-sync/pre-warmup" the content of the git_dirs from existing merger/executors? | 20:48 |
| @clarkb:matrix.org | Kenny Ho: I don't think there are any issues with presyncing. I would just make sure yo uuse the correct file permissions | 20:51 |
| @clarkb:matrix.org | I think tobiash may pre sync too? | 20:51 |
| @fungicide:matrix.org | > <@gobi_g:matrix.org> fungi: got it. One last request. Could please share reference for that branch specific job configuration? | 20:53 |
| * there are two ways to do branch-specific jobs.. one is implicit branch matching, basically adding jobs in the project configuration on branches where you want them to run (this is most common with in-project configuration). the other way is explicit branch matchers, `branches` arguments in the job definitions or variants (most common when the jobs are defined in a different repository than the one for which they're being run, e.g. a trusted config project) | ||
| @y2kenny:matrix.org | ok thanks. I will give that a try. | 20:53 |
| @fungicide:matrix.org | not only permissions, but ownership may be important as well | 20:54 |
| @y2kenny:matrix.org | thanks fungi I will be sure to double check that also. My deployment is on top of k8s so things should be fairly uniform. | 20:56 |
| -@gerrit:opendev.org- Zuul merged on behalf of James E. Blair https://matrix.to/#/@jim:acmegating.com: [zuul/zuul] 832391: Remove inactive maintainers https://review.opendev.org/c/zuul/zuul/+/832391 | 21:57 | |
| -@gerrit:opendev.org- James E. Blair https://matrix.to/#/@jim:acmegating.com proposed: [zuul/zuul] 832870: Make promote work for any pipeline manager https://review.opendev.org/c/zuul/zuul/+/832870 | 23:04 | |
Generated by irclog2html.py 2.17.3 by Marius Gedminas - find it at https://mg.pov.lt/irclog2html/!