| frickler | seems no progress has been made on the ports mirror? so next up I'm going to try an manually download the files it is complaining about as missing | 07:00 |
|---|---|---|
| mnasiadka | is there an option to have a zuul job variable that would be reused in other job variables? as in image: "1234.56" image2: "something{{ image }}.qcow.gz" ? | 11:18 |
| mnasiadka | (haven't tried, but wanted to ask before I fail miserably) :) | 11:18 |
| frickler | after downloading all missing files ubuntu-ports should now be updated. cc mnasiadka | 12:11 |
| mnasiadka | frickler: thanks! | 12:12 |
| fungi | thanks frickler! i didn't end up getting a chance to look into options for force-redownloading those | 12:41 |
| opendevreview | Merged openstack/project-config master: Add magnum-capi-helm repo to Magnum project https://review.opendev.org/c/openstack/project-config/+/910239 | 12:55 |
| SvenKieske | mnasiadka: IIRC you should be able to just use yaml anchors for zuul job variables? gitlab has actually nice docs about yaml anchors and aliases and map merging in general, that should not be tool specific: https://docs.gitlab.com/ee/ci/yaml/yaml_optimization.html | 14:25 |
| SvenKieske | mnasiadka: if you prefer a link to the spec, that's here, but afaik it hasn't got any real world examples, so it's a litte dry to read imho: https://yaml.org/spec/1.2.2/#3222-anchors-and-aliases | 14:27 |
| fungi | yeah, you can use yaml anchors in zuul configuration, but it's per document so you can't put an anchor in one config and then expand it in another | 14:28 |
| fungi | all has to happen within the same file, basically | 14:29 |
| SvenKieske | right :) :D | 14:29 |
| SvenKieske | never ocurred to me that you might want to use this across more than one file, but, yeah, I can see that happening. I guess the parser goes over every file one by one. | 14:30 |
| SvenKieske | funnily enough in the zuul docs it's only mentioned in passing in the docker jobs documentation, at least my search didn't turn it up anywhere else. | 14:30 |
| SvenKieske | made me question if it's even supported everywhere | 14:31 |
| corvus | SvenKieske: what is "it" ? that you're questioning is supported everywhere? | 14:31 |
| fungi | corvus: yaml anchor definition/expansion | 14:32 |
| corvus | oh that's part of the yaml spec. | 14:33 |
| fungi | i think the zuul docs don't go deep into that topic because it's a part of yaml itself, not really zuul-specific (and the parser flattens it all before it reaches zuul) | 14:33 |
| SvenKieske | yeah, I just wasn't sure if any zuul job is yaml at it's core. it's not explicitly stated anywhere I guess? I think it's just assumed everyone knows that? :) | 14:34 |
| SvenKieske | s/any/every/ | 14:35 |
| fungi | well, the zuul jobs aren't, the files you're defining them within are yaml | 14:35 |
| fungi | jobs are basically data structures | 14:35 |
| SvenKieske | yeah, that's what I meant. | 14:35 |
| corvus | SvenKieske: heh that's a good point and you made me check whether we actually say "the config is yaml", but good news, we do! https://zuul-ci.org/docs/zuul/latest/project-config.html#configuration-items | 14:36 |
| SvenKieske | so https://zuul-ci.org/docs/zuul-jobs/latest/jobs.html has no general introduction what a "Job" even is, like "jobs are defined in yaml files...blabla" just a list of specific jobs which have specific keywords | 14:37 |
| corvus | so yeah, i think the expectation for any system using yaml is that it would support the full spec including anchors, etc. otherwise i think someone should describe that as "similar to yaml" or something like that. but to be clear, zuul is fully yaml spec compliant. :) | 14:37 |
| SvenKieske | nice | 14:37 |
| corvus | SvenKieske: that's the documentation for the standard library of zuul jobs, not zuul itself. think of that like the docs for libc (printf, etc) | 14:37 |
| SvenKieske | ah, so I didn't look into the right place, I had a suspicion that might be the case | 14:37 |
| corvus | mnasiadka: the simple answer to your question about variable composition is "yes" | 14:38 |
| fungi | SvenKieske: there is also a glossary which has a definition of various terms like job and build, but improvements are welcome as always | 14:38 |
| SvenKieske | going back in history I landed there via this google search: https://www.google.com/search?client=firefox-b-d&q=zuul+job+variables+yaml+anchors the second link is https://zuul-ci.org/docs/zuul-jobs/latest/docker-jobs.html | 14:38 |
| mnasiadka | single file is not ideal, but I can make this work - thanks | 14:39 |
| corvus | mnasiadka: a longer answer is "yes -- because it's passed through to ansible and ansible handles that" | 14:39 |
| corvus | mnasiadka: an even longer answer is "yes -- because it's passed through to ansible and ansible handles that, however, there are some important caveats about security in zuul jobs and trusted/untrusted playbooks, so you should read the docs at https://zuul-ci.org/docs/zuul/latest/config/job.html#attr-job.vars and see if any of those conditions apply" | 14:40 |
| corvus | mnasiadka: and you can always just try it out. here is your example made real: https://zuul.opendev.org/t/openstack/build/839f26e9748146fb9bdece3e7be2f50d/log/job-output.txt#76 https://review.opendev.org/c/opendev/sandbox/+/912587/1/.zuul.yaml | 14:41 |
| mnasiadka | corvus: nice, that's easier than anchors - forgot that I could test in sandbox :) | 14:42 |
| SvenKieske | for single file usage I find anchors to actually be the fastest and easiest solution, though not every reviewer understands this part of yaml immediately | 14:44 |
| SvenKieske | but I guess it's a matter of opinion | 14:44 |
| corvus | yeah, they're both great tools to have. variable composition is useful if you want to use the inheritance hierarchy to make job variations; so using it for things like mnasiadka can facilitate making thin job variants for different versions. | 14:45 |
| corvus | anchors are good for DRY without inheritance relationships | 14:46 |
| corvus | er, that should say "things like mnasiadka's example" | 14:47 |
| fungi | also, marking a job "abstract" if it's only used for inheritance purposes is good hygiene to avoid a project actually trying to run it directly | 14:47 |
| NeilHanlon | https://www.openwall.com/lists/oss-security/2024/03/12/5 fyi: OVN CVE 🙃 | 14:52 |
| clarkb | we don't run any OVN ourselves. It is interesting that they imply it should be mitigated by clouds rather than just patching ovn | 14:54 |
| clarkb | I guess they say you can do both thinsg givingyou the option | 14:54 |
| NeilHanlon | yeah i thought that was interesting as well; and, ack--wasn't sure what we were using | 14:55 |
| fungi | we basically don't operate our own networks, we just use cloud providers who take care of that | 14:56 |
| NeilHanlon | that's smart :) | 14:56 |
| fungi | smart and lazy often go hand in hand | 14:57 |
| NeilHanlon | :D i hear that.. | 14:57 |
| fungi | and to be clear, clarkb and i have both worked as network engineers in past lives, so we know from first hand experience lots of good reason not to take that on ;) | 15:08 |
| clarkb | something something spanning tree loops | 15:08 |
| fungi | so many ebgp pads and prefs | 15:09 |
| fungi | full bridge tables | 15:09 |
| fungi | pmtud blackholes | 15:10 |
| mnasiadka | networking is hard | 15:12 |
| NeilHanlon | fungi: yeahhh... i've been there too.. unfortunately I have little choice in some environments but to run (some) network. Though I keep it as simple as reasonably possible :D | 15:16 |
| mnasiadka | corvus: is there a way to override required-projects using a job-template (or maybe even override that on pipeline/project level)? I'm either blind skimming the docs, or that's not possible. | 15:30 |
| clarkb | mnasiadka: some attributes are overridden when inherited and set and others are merged. The docs should indicate what the behavior is | 16:26 |
| clarkb | "This attribute is not overridden by inheritance; instead it is the union of all applicable parents and variants" | 16:26 |
| clarkb | from https://zuul-ci.org/docs/zuul/latest/config/job.html#attr-job.required-projects | 16:27 |
| mnasiadka | clarkb: I was rathering thinking if on project level (https://zuul-ci.org/docs/zuul/latest/config/project.html#attr-project.templates) I can override required-projects - I ended up with https://review.opendev.org/c/openstack/magnum-capi-helm/+/912577/9/.zuul.yaml - but would prefer some more... elegant solution. | 16:30 |
| mnasiadka | I've noticed definitions like - https://opendev.org/openstack/openstack-zuul-jobs/src/commit/8325a38fa9812536636b9fc05c7a4c5ceb25cbea/zuul.d/project-templates.yaml#L749 | 16:30 |
| clarkb | mnasiadka: right the docs say required-projects cannot be overridden only expanded | 16:30 |
| clarkb | but you can define a variant of a job and add extra required projects | 16:31 |
| clarkb | yes that is additive not overriding | 16:31 |
| mnasiadka | Wondering which is a better option - since it's an out of tree driver that needs magnum code for testing - I'll probably end up with locally defined jobs (since we probably need to run unit tests and functional tests for every supported stable release of Magnum - since the out of tree driver will have an independent release model - one branch and tags only) | 16:33 |
| opendevreview | Clark Boylan proposed zuul/zuul-jobs master: Pin requests-oauthlib<1.4.0 under python2.7 https://review.opendev.org/c/zuul/zuul-jobs/+/912603 | 17:22 |
| opendevreview | Merged zuul/zuul-jobs master: Pin requests-oauthlib<1.4.0 under python2.7 https://review.opendev.org/c/zuul/zuul-jobs/+/912603 | 17:51 |
| opendevreview | Merged zuul/zuul-jobs master: Drop CentOS 7 test jobs https://review.opendev.org/c/zuul/zuul-jobs/+/912280 | 18:23 |
| opendevreview | Merged openstack/project-config master: Add op to #openstack-outreachy https://review.opendev.org/c/openstack/project-config/+/911954 | 18:42 |
| opendevreview | Jeremy Stanley proposed opendev/system-config master: Deduplicate Rackspace control plane API keys https://review.opendev.org/c/opendev/system-config/+/912632 | 19:19 |
| hashar | fungi: I guess if you feel brave you could tag a new release of `git-review` such as 2.4.0 maybe? vendoring the Gerrit hook script sounds like an excellent idea :) | 20:18 |
| fungi | hashar: yes, the plan is to tag what's already merged as 2.4.0, i just need to add some release notes for changes which we forgot to ask contributors to write before we merged those changes | 20:25 |
| hashar | fungi: amazing! thank you for the continued maintenance :) | 20:26 |
| fungi | it seems like the missing release notes we still need (based on feedback so far) are: ce90966 "feat(cmd): add hashtag implementation", 52752c8 "Add message option", 21d9ceb "Use GIT_SSH for the SSH executable", 702a1dc "Warn rather than fail if HEAD already exists on the remote", 0502235 "Add --wip as an alias to --work-in-progress" | 20:31 |
| fungi | and also i'm going to fix some of the rst markup in the two existing release notes | 20:35 |
| * fungi sighs at more missing manpage entries | 20:35 | |
| fungi | made all the worse by the fact that i approved some of these | 20:36 |
| opendevreview | Jeremy Stanley proposed opendev/git-review master: Add missing release notes and manpage updates https://review.opendev.org/c/opendev/git-review/+/912653 | 21:00 |
| fungi | clarkb: corvus: frickler: hashar: ^ | 21:00 |
| fungi | getting in a quick walk before dark, since the weather's turned surprisingly pleasant, but will be back soon | 21:09 |
| clarkb | I was just about to start thinking about going outside then it began dumping hail | 21:12 |
| clarkb | now that I've given up for the moment the sun came back out again | 21:12 |
| clarkb | I've just discovered teh "included in" dialog in gerrit this is a great little feature | 21:23 |
| clarkb | https://etherpad.opendev.org/p/apr2024-ptg-opendev has content now. | 21:53 |
| clarkb | talking out loud on the problem of centos 7 cleanup. One thing we could do is offer to bypass CI for chagnes that simply remove jobs | 22:03 |
| clarkb | that is a relatively straightforward task and relatively safe (you'll at worst create a similar problem in another repo) | 22:04 |
| fungi | ugh, going through the keystone stable branches it looks like we're in for a treat when we decide to remove xenial | 22:14 |
| fungi | tempted to backport https://review.opendev.org/908850 since it cleans up centos-7, ubuntu-xenial and opensuse-15 references | 22:14 |
| fungi | but not sure if that's premature for, e.g., the unmaintained/yoga branch | 22:15 |
| clarkb | fungi: I think yoga was in the bionic era wasn't it | 22:16 |
| fungi | yes | 22:16 |
| clarkb | its probably fine to backport | 22:16 |
| fungi | yeah, trying. cherry-picked cleanly until i reached zed | 22:19 |
| fungi | mostly just conflicting over unrelated churn in their zuul config | 22:19 |
| fungi | okay, keystone backports are up | 22:23 |
| fungi | openstack/solum and openstack/neutron-vpnaas need the same cleanup starting in master though | 22:24 |
| fungi | also we'll probably need to remove x/networking-opencontrail from the tenant config | 22:24 |
| clarkb | are those needing cleanup because the use the devstack nodeset or just general centos-7 usage | 22:27 |
| fungi | the specific devstack nodeset we're trying to remove | 22:28 |
| fungi | i obviously check configs for other centos-7 references while i'm editing though | 22:28 |
| clarkb | ack was just wondering what sort of centos 7 things we had going on | 22:29 |
| clarkb | and yes the xenial cleanup is going to be interesting | 22:29 |
| clarkb | it really does reinforce that semi regular pruning is important | 22:29 |
| clarkb | there is no reason for these decade old distros to be on master branches of openstack projects that haven't properly supported those versions of python runtimes for years | 22:30 |
| clarkb | though i guess if the jobs are running they may inadverdently do so | 22:30 |
| fungi | in the neutron-vpnaas case, for example, the job definition is there but the job is commented out in their project pipelines with a # todo: make this work with centos 8 | 22:30 |
| fungi | maybe we also need to reinforce that it's okay to remove this stuff, even temporarily, nothing is ever truly deleted in git | 22:31 |
| clarkb | ++ | 22:35 |
| fungi | yeesh, did 9 branches of neutron-vpnaas | 22:45 |
| fungi | looks like solum will need 8 | 22:46 |
| clarkb | the wheels of tech debt keep turning :) | 22:49 |
| fungi | keystone was thankfully only 7 branches since they'd already deleted it on master | 22:49 |
| opendevreview | Jeremy Stanley proposed openstack/project-config master: Drop gating for x/networking-opencontrail https://review.opendev.org/c/openstack/project-config/+/912678 | 22:58 |
| fungi | okay, if all the changes i just pushed manage to merge, we'll be able to merge the centos-7 removal from the remaining devstack branch | 22:59 |
| fungi | 25 changes in total (not counting the 8 for devstack itself) | 23:00 |
| opendevreview | Jeremy Stanley proposed opendev/git-review master: Add missing release notes and manpage updates https://review.opendev.org/c/opendev/git-review/+/912653 | 23:17 |
| opendevreview | Jeremy Stanley proposed opendev/git-review master: It's patchset not patch set https://review.opendev.org/c/opendev/git-review/+/912681 | 23:17 |
| fungi | i have a feeling there are a lot more references to devstack-single-node-centos-7 nodesets lurking in older stable branches of random openstack projects, which i'm not going to be able to find without scripting a git clone and grep over every branch of every repo | 23:34 |
Generated by irclog2html.py 2.17.3 by Marius Gedminas - find it at https://mg.pov.lt/irclog2html/!