| tkajinam | join #opendev-events | 04:25 |
|---|---|---|
| opendevreview | Dr. Jens Harbott proposed openstack/project-config master: Only pause update_constraints.sh when needed https://review.opendev.org/c/openstack/project-config/+/946541 | 09:39 |
| opendevreview | Matt Anson proposed openstack/diskimage-builder master: Remove qemu-debootstrap from debootstrap element https://review.opendev.org/c/openstack/diskimage-builder/+/946550 | 11:57 |
| fungi | ptg seems to be going smoothly so far, i was in a two-hour meetpad session for the openstack tc with a bunch of participants | 15:03 |
| opendevreview | Merged openstack/project-config master: Replace 2025.1/Epoxy key with 2025.2/Flamingo https://review.opendev.org/c/openstack/project-config/+/945247 | 15:46 |
| JayF | question from ironic team in PTG (cc dtantsur iurygregory rpittau TheJulia) -- is it possible to have a label vote or a topic trigger CI? | 15:50 |
| JayF | e.g. NetworkingImpact+1 -> run this extra set of networking jobs (or could even mean "run experimental jobs" if that's how it had to be structured) | 15:50 |
| iurygregory | ++ | 15:52 |
| JayF | The idea is to remove the most environmentally-dependant ironic jobs from the main queue and only trigger them for the changes they need. Not just to preserve resources but also to prevent the need for recheck. | 15:53 |
| Clark[m] | Yes, you can put them in the experimental queue and leave a "check experimental" comment | 16:02 |
| dtantsur | Not sticky, won't be added to the gate pipeline | 16:04 |
| dtantsur | not specific enough | 16:04 |
| Clark[m] | Ok let's backup then because that's a ton of extra requirements that weren't initially stated. You want to run "check" style jobs but only when necessary and have that he sticky so that new patch sets automatically run them and then also automatically run them in the gate too? | 16:06 |
| dtantsur | Okay, we can ignore the gate part for now, but yes, everything else is correct. | 16:07 |
| dtantsur | The sticky part will ensure we don't accidentally merge the very last revision without actually running the relevant test | 16:07 |
| Clark[m] | The easiest way to accomplish that will be with file matchers on the jobs that prevent them from running if not necessary. You can also have a dependent job use zuul_return to dynamically remove jobs from the job list based on whatever criteria the job has access to. But there is no pipeline that will do this for you | 16:08 |
| dtantsur | A job that defines which jobs run after it? Mmmmm, may work. | 16:09 |
| dtantsur | Do jobs have any access to gerrit, Clark[m]? or would we need to use some other logic? | 16:09 |
| Clark[m] | Zuul 's top level triggers are based on static criteria and we have tried to make those as generic as possible rather than encode project specific logic in them | 16:10 |
| Clark[m] | The dynamic options are basically handled in the jobs via things like matchers and zuul_return | 16:10 |
| JayF | using file-based triggers is not a terrible idea as a middle-way to get here, as long as we could run those jobs (or variations from them) on demand as well | 16:10 |
| JayF | if we can't ID what changes will most likely impact networking by module/file, we might need to factor our code better | 16:10 |
| dtantsur | Let's use AI to detect the scope of the patch :D | 16:11 |
| * dtantsur ducks | 16:11 | |
| JayF | if you're going to make that joke, do it somewhere adamcarthur5 isn't | 16:11 |
| JayF | he's crazy, he'll do it :D | 16:11 |
| dtantsur | As long as its license status is clear :) | 16:11 |
| dtantsur | Seriously though, if we have a job that defines which jobs to run, we can run smarter checks than "what file is changed" | 16:11 |
| JayF | dtantsur: https://review.opendev.org/c/openstack/ironic-tempest-plugin/+/943086 all following OpenInfra foundation policy :D | 16:11 |
| dtantsur | Clark[m]: are there any examples in the wild of a job that uses zuul_return to enable/disable jobs? | 16:14 |
| dtantsur | I guess I understand the docs, but a real example would be better | 16:14 |
| corvus | btw we call that a "dispatch job" | 16:14 |
| Clark[m] | I am not aware of any examples. corvus may know | 16:15 |
| corvus | i'm not aware of any off-hand in opendev | 16:16 |
| dtantsur | Dispatch job, nice! Okay, thank you folks, appreciated. We now need to digest this information in our group. | 16:17 |
| corvus | using file matchers is preferable for efficiency, so if you can do that, it's better. but if the logic isn't encodable in a file matcher, then the dispatch job pattern is an option. | 16:18 |
| corvus | (if you do a dispatch job, try to make it something lightweight that can run on the executor so you don't have to wait for a node) | 16:19 |
| corvus | also, consider gerrit hashtags as way to make information about a change sticky | 16:19 |
| dtantsur | Lightweight as in: a python script is fine, devstack is not? Or are there harsher restrictions? | 16:19 |
| dtantsur | Can I access hashtags from a job? | 16:20 |
| fungi | as for custom labels, i think the openstack sdk team was fiddling with a way to authorize sensitive testing to run by triggering it with a separate core review vote | 16:20 |
| JayF | a hashtag is a great interface given we already allow anyone to set them in ironic | 16:20 |
| dtantsur | oh yeah, I think I've seen the openstacksdk thing, hence this idea | 16:20 |
| fungi | though in the sdk case it was (going to be) for remote testing with public cloud accounts | 16:20 |
| JayF | fog used to do that, with unmocked tests that hit APIs directly. A little crazy but made it easy to develop against | 16:21 |
| dtantsur | reminds me of /ok-to-test in the CNCF world :) | 16:21 |
| dtantsur | So, if we can find a way to get hashtags for the change from a dispatch job, it'll be a good way to do it | 16:22 |
| Clark[m] | You should be able to anonymously query hashtags from gerrits API if it isn't already in your inventory (you can just check your builds logs on an existing build for that) | 16:24 |
| dtantsur | Good point | 16:24 |
| dtantsur | Not in the inventory, but should be easy to fetch indeed | 16:29 |
| corvus | with recent changes to zuul, the tenant reconfiguration time for openstack is now about 10s (down from about 27s before) | 16:53 |
| fungi | nice! | 17:42 |
| fungi | ptg sessions have wrapped up for the next few hours, so i'm going to pop out for a late lunch/early dinner now, should be back by 19:00 utc | 18:03 |
| fungi | and still quiet | 19:09 |
Generated by irclog2html.py 2.17.3 by Marius Gedminas - find it at https://mg.pov.lt/irclog2html/!