| Clark[m] | tonyb: today is looking like a hide from the heat day. Did you want to dig into the fedora stuff in a couple ish hours? | 00:31 |
|---|---|---|
| tonyb | perfect | 00:32 |
| tonyb | about 4 hours from now I need to grab kids from school | 00:32 |
| Clark[m] | Sounds good I'll check back in after lunch | 00:33 |
| clarkb | tonyb: ok I'm around now | 02:05 |
| tonyb | I'm looking at thew mirroring stuff | 02:05 |
| tonyb | Kinda thinking about what the ansible will look like | 02:06 |
| tonyb | SIlly question, is there a way to tell zuul ... "ignore this change for now it isn't worth testing" ? | 02:07 |
| clarkb | you can remove all the jobs from the job list | 02:08 |
| clarkb | but other than that no | 02:08 |
| clarkb | then basically revert the file back to its normal state when ready to get it CI'd | 02:08 |
| clarkb | I think what we want to do is update the base-test pre.yaml playbook to run the new role | 02:08 |
| clarkb | and then iterate on that until we're confident it works reliably on the various platforms | 02:09 |
| tonyb | Yeah I was panning on doing that. I was going to modify the existing role, but I guess I can do it via a new role instead | 02:09 |
| clarkb | ya unfortunately we lose all of the speculative power of zuul in these trusted areas | 02:10 |
| tonyb | kinda import-role ... \nwhen: zuul_mirrorinfo is defined | 02:10 |
| clarkb | so we end up doing hacky things like copying roles and modifying them and testing with base-test | 02:10 |
| tonyb | Ahh okay | 02:11 |
| clarkb | all of that is clunky but is the approach that seems to work best | 02:11 |
| tonyb | I'm going to start with 'pip | 02:15 |
| tonyb | ' as that's the easy one :) | 02:15 |
| opendevreview | Clark Boylan proposed opendev/system-config master: Update to Gitea 1.20 https://review.opendev.org/c/opendev/system-config/+/886993 | 03:26 |
| tonyb | ANother silly question. per-cloud mirrors don't actually block access from users outside of that cloud right? For local testing I could spin up a VM/Container and point it at a region/cloud combo and get a, probably slow, but finctional mirror | 03:34 |
| clarkb | correct | 03:35 |
| tonyb | clarkb: 886993 is getting kinda ... long | 03:35 |
| clarkb | we warn people not to use them because w ecan and do remove content from the mirrors but they are publicly available since it simplifies a lot of things | 03:35 |
| clarkb | tonyb: ya this particular gitea upgrade is turning out to be an annoying one. The good news is most of it is in template updates that mostyl don'y affect us and the oauth2 stuff | 03:36 |
| clarkb | I'm hoping they might fix the oauth2 stuff and we can trim that back out | 03:36 |
| tonyb | clarkb: re mirror stuff. I'm gussing you knwo but for clarity/logs I only want to use it to test before/after my new mirror info role | 03:37 |
| clarkb | use it? | 03:39 |
| tonyb | clarkb: re gitea 1.20.x Yeah It'd be nice if they at least laned the oauth2 fix. I get that they aren't going to fix the broader config needs to be writeable, and the templates stuff seems to be a "we forked the templates" kinda situation | 03:39 |
| tonyb | clarkb: use it as in ... spin up a container here run my new config-mirrors (via mirrorinfo) and verify that the urls look right for a given region/cloud | 03:41 |
| tonyb | local testing before I publish etc | 03:41 |
| clarkb | ah yup. Its totally fine to use for that purpose. More of a don't configure your productio nservers to use our mirrors | 03:42 |
| tonyb | Got it :) | 03:43 |
| clarkb | I'm going to pop out now | 04:19 |
| tonyb | kk | 04:26 |
| opendevreview | Merged openstack/project-config master: Add Intel Ethernet Operator app to StarlingX https://review.opendev.org/c/openstack/project-config/+/887941 | 12:20 |
| *** jgwentworth is now known as melwitt | 16:18 | |
| corvus | #status log deleted old zuul executor servers | 16:44 |
| opendevstatus | corvus: finished logging | 16:44 |
| fungi | thanks! | 16:57 |
| ildikov | Hello OpenDev Team, I have a quick question that I need pointers with. The StarlingX community is experiencing issues with the Launchpad Gerrit hook. The 'Closes-Bug' tag in the Gerrit commit message turns into a link to the bug, as expected. But, the Launchpad bug does not get updated with the patch info. Has anyone experienced the same lately? | 17:19 |
| ildikov | ie: https://bugs.launchpad.net/starlingx/+bug/2028302 | 17:20 |
| fungi | ildikov: yes, they about it a couple of weeks ago and we merged https://review.opendev.org/888321 to fix it but may still need a gerrit restart for it to take effect | 18:13 |
| fungi | er, they asked about it | 18:13 |
| fungi | it was specifically affecting projects where the project name in gerrit doesn't match the project name in launchpad, so presumably not affecting all their changes? | 18:14 |
| fungi | i think it came up with starlingx/docs changes because those use the stx-docs project in lp | 18:14 |
| ildikov | fungi: ah, ok, got it | 18:16 |
| ildikov | the examples I got pointed at were for different project teams, but they potentially fall under that same category | 18:16 |
| ildikov | fungi: is there a way to figure out if it's a Gerrit restart that's needed for that fix to take affect? | 18:18 |
| ildikov | or if there's something else in the background? | 18:18 |
| fungi | i need to take a look at how jeepyb is getting injected into the gerrit environment, but if it's baked into the container image we're using like i suspect, then we'll need to restart onto the rebuilt image | 18:22 |
| fungi | and yeah, i'm almost certain that's it because we build and upload new gerrit images every time we merge a change to jeepyb | 18:23 |
| ildikov | fungi: ok, that makes sense, thanks for clarifying | 18:23 |
| fungi | last gerrit restart was on may 12, well before that revert change merged | 18:23 |
| fungi | so we just need to pick a convenient low-impact time to restart it, i'll add that to tomorrow's meeting agenda. thanks for the reminder! | 18:24 |
| ildikov | I checked the LP examples and they were also well after the fix, so things seem to line up with your suspicion | 18:25 |
| ildikov | sounds great, thank you! | 18:25 |
| Clark[m] | fungi: if we are going to do a Gerrit restart we should consider landing the 3.7.4 image update change first and also make a plan for dealing with the replication task file leaks. Otherwise we'll like get hundreds of thousands of errors on startup | 19:12 |
| fungi | that's a great point. i'll take another look at the gerrit update now | 19:14 |
| fungi | as for the replication task leaks, i wonder if we can somehow get gerrit's replucation to a quiescent state and then clear any queue contents? | 19:22 |
| Clark[m] | Ya we could stop Gerrit. Then just delete everything in that dir. We might miss some things but if we do it during a Gerrit quiet time we reduce chances of that | 19:24 |
| Clark[m] | And it isn't any different than the behavior we had in the past | 19:24 |
| Clark[m] | Maybe that is a good stopgap procedure for now | 19:25 |
| fungi | fair. i guess actually quieting it would involve pausing zuul and blocking ssh/https access temporarily | 19:25 |
| fungi | which is probably worse than missing a queued task | 19:25 |
| fungi | #status log Set Gerrit's receive.rejectImplicitMerges option per https://review.opendev.org/885318 | 19:34 |
| opendevstatus | fungi: finished logging | 19:34 |
| opendevreview | Merged opendev/system-config master: Enable receive.rejectImplicitMerges for Gerrit https://review.opendev.org/c/opendev/system-config/+/885318 | 19:42 |
Generated by irclog2html.py 2.17.3 by Marius Gedminas - find it at https://mg.pov.lt/irclog2html/!