| @fungicide:matrix.org | Kenny Ho: that's very useful info. in opendev our zk cluster is 3x 4gb ram virtual machines in a public cloud provider, with the data store just on the rootfs, so i *assume* those are sata-backed. we also might get more responsiveness if we moved the zk data onto ssd, i guess | 13:06 |
|---|---|---|
| @fungicide:matrix.org | the provider we're using has the option of attaching separate (ssd or sata) virtual backed block devices | 13:07 |
| @fungicide:matrix.org | * the provider we're using has the option of attaching separate (ssd or sata) backed virtual block devices | 13:08 |
| @fungicide:matrix.org | * the provider we're using has the option of attaching separate ssd or sata backed virtual block devices | 13:09 |
| @jpew:matrix.org | Hmm, it looks like the way that Zuul uses compressed logs is impossible to use with nginx as a server frontend.... it looks like it's using some quirks of apache to work correctly | 13:15 |
| @jpew:matrix.org | Specifically, when serving the pre-compressed files, ngninx doesn't set the `content-encoding` header, which the Zuul Web UI then rejects and thus won't show any logs | 13:17 |
| -@gerrit:opendev.org- Tristan Cacqueray proposed: [zuul/zuul-operator] 852855: Update zookeeper image version to the latest release 3.8 https://review.opendev.org/c/zuul/zuul-operator/+/852855 | 13:32 | |
| @jpew:matrix.org | Ah, nevermind, you can do it with this block | 13:42 |
| ``` | ||
| location ~* \.gz$ { | ||
| add_header Content-Encoding "gzip"; | ||
| } | ||
| ``` | ||
| @fungicide:matrix.org | jpew: for the record, opendev's zuul doesn't even run a log serving site, we just push logs to object storage in public clouds and rely on their features to determine how to serve stuff to browsers | 13:54 |
| @fungicide:matrix.org | so if you follow raw log links from zuul.opendev.org you end up going straight to some public cloud object store | 13:55 |
| @jpew:matrix.org | fungi: Fair enough. It would be a little more convinent if the compressed logs worked better with a default webserver configuration, but it's not the end of the world | 13:55 |
| @fungicide:matrix.org | i expect we'd accept patches for that if it can be done in a backward-compatible way and not create regressions for people who rely on the current compression features | 13:57 |
| @jpew:matrix.org | FWIW, it's more user friendly to set the configuration options since that will transparently decompress the files for viewing in browsers; maybe zuul-jobs should just have better documentaition about how to configure it for nginx and apache | 13:58 |
| @fungicide:matrix.org | jpew: i've never used nginx, but did you try https://nginx.org/en/docs/http/ngx_http_gzip_static_module.html | 13:59 |
| @jpew:matrix.org | fungi: Ya, here is the block you need to make it all work: | 14:01 |
| ``` | ||
| gzip_types text/plain application/json; | ||
| gzip_proxied no-cache no-store private expired auth; | ||
| gunzip on; | ||
| gzip_static always; | ||
| location ~* \.gz$ { | ||
| add_header Content-Encoding "gzip"; | ||
| } | ||
| ``` | ||
| ... well `gzip_types` and `gzip_proxied` may not be strictly necessary..... | ||
| -@gerrit:opendev.org- Simon Westphahl proposed: [zuul/zuul] 852859: Fix zoned executor metric when unzoned is allowed https://review.opendev.org/c/zuul/zuul/+/852859 | 14:05 | |
| @g_gobi:matrix.org | Hi, | 15:38 |
| Currently when I add 5 pipelines in zuul. | ||
| It will show in the dashboard like following order: | ||
| ``` | ||
| pipeline1. pipeline2. pipeline3 | ||
| pipeline4 pipeline5 | ||
| ``` | ||
| Is there any way to change or group the pipelines in UI? Because these pipelines are from different projects. So, group by project or show the pipelines in projectwise like | ||
| ``` | ||
| pipeline1 pipeline2. | ||
| pipeline3 | ||
| pipeline4 pipeline5 | ||
| ``` | ||
| thanks | ||
| @jim:acmegating.com | Gobi G: pipelines are displayed on the status page in the order they are defined in the configuration. that's the only control over their display that is available. | 15:45 |
| -@gerrit:opendev.org- James E. Blair https://matrix.to/#/@jim:acmegating.com proposed: [zuul/nodepool] 852670: Add support for dynamic tags https://review.opendev.org/c/zuul/nodepool/+/852670 | 18:56 | |
| @jpew:matrix.org | I would like Zuul to have a branch filter like `job.irrelevent-files` that decides if the job should be run or not based on the branch, but unlike the behavior of `job.branches` which determines if the job variant is valid for a given branch (e.g. I only want the job to run on a set of branches that match a given regex, and may not run on a branch with a different name that forks from it). Does this sound reasonable? I was thinking something like `job.branch-filter.exclude` ? | 19:20 |
| @clarkb:matrix.org | you can use negative lookahead matches on job.branches which allows you to exclude things | 19:21 |
| @jpew:matrix.org | @clark but that determines if the variant is valid, it will just choose a variant from another branch which is not what I want | 19:23 |
| @jpew:matrix.org | (right?) | 19:23 |
| @jim:acmegating.com | if there are no matching branch variants, the job doesn't run | 19:28 |
| @jpew:matrix.org | yes... but my understanding is that `job.branches` says "this job (regardless of which branch it's defined on) is a valid variant for branches that matches these regexes", which isn't what I want. I always want jobs (variants) to only be valid for the branch they are defined on; but I want (e.g.) a branch made from `master` to run no jobs by default unless the user goes in and changes the config to enable them | 19:31 |
| @jpew:matrix.org | Sorry if I'm just missing how this can be done with `job.branches` I'm really scared of it because it burned us hard when we first started using zuul | 19:32 |
| @clarkb:matrix.org | You can remove the job from master's pipeline list | 19:34 |
| @jim:acmegating.com | consider also using project stanzas for deciding whether to run jobs or not | 19:34 |
| @jim:acmegating.com | what Clark said | 19:34 |
| @jim:acmegating.com | i think it's easier to follow to use project-pipeline stanzas to control which jobs run, and job.branches to alter them for branch-specific behavior. | 19:35 |
| @jpew:matrix.org | I mean... sure. the first commit you make on every branch you cut from master could be to disable everything you don't want to run | 19:36 |
| @jpew:matrix.org | But the users making those branches really just want it to do the right thing by default | 19:37 |
| @jim:acmegating.com | you could also add branch matchers to the jobs in project stanzas which could be used to invert the logic like you suggest. those branch matchers can also use negative lookaheads | 19:37 |
| @jpew:matrix.org | I feel like I'm missing some important concept here :/ | 19:39 |
| @jpew:matrix.org | Wouldn't I need to have that same negative look ahead on all branches in my project in order for a job to not get picked up from a given branch? | 19:41 |
| @jim:acmegating.com | the anonymous job variant that is created in a project-pipeline stanza can have any job attribute set on it, including `branches` so it can include a negative lookahead. if there are no matching jobs in the project-pipeline, the job doesn't run. (further if there are no matching job stanzas, the job doesn't run either, but you established why you don't want to rely on that). | 19:43 |
| @jpew:matrix.org | Ok, so if I did this: | 19:45 |
| ``` | ||
| - project: | ||
| gate: | ||
| - foo: | ||
| branches: master | ||
| ``` | ||
| it would only run the job foo on the master branch, and this is different than | ||
| ``` | ||
| - job: | ||
| branches: master | ||
| ``` | ||
| which means anytime the branch forked it made a new job that could be selected to run on master and cause all sorts of problems for ut | ||
| @jpew:matrix.org | * Ok, so if I did this: | 19:45 |
| ``` | ||
| - project: | ||
| gate: | ||
| - foo: | ||
| branches: master | ||
| ``` | ||
| it would only run the job foo on the master branch, and this is different than | ||
| ``` | ||
| - job: | ||
| branches: master | ||
| ``` | ||
| which means anytime the branch forked it made a new job that could be selected to run on master and cause all sorts of problems for us | ||
| @jpew:matrix.org | when we did the later, we had all sorts of confusing behavior where zuul would select out of date variants from other branches because there were multiple jobs that could run for the master branch, and calamity enused | 19:48 |
| @jpew:matrix.org | * when we did the later, we had all sorts of confusing behavior where zuul would select out of date variants from other branches because there were multiple jobs that could run for the master branch, and calamity ensued | 19:48 |
| @jpew:matrix.org | (At least thats how I rationalized it in my head :) ) | 19:48 |
| @clarkb:matrix.org | jpew: yes you should really only use the job branches attribute on a single branch config project | 21:50 |
| @clarkb:matrix.org | then you don't have the problem of branches forking with confusing rules. Everything is contained on a single branch directing everything else | 21:50 |
Generated by irclog2html.py 2.17.3 by Marius Gedminas - find it at https://mg.pov.lt/irclog2html/!