Monday, 2023-07-24

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
tonybperfect 00:32
tonybabout 4 hours from now I need to grab kids from school 00:32
Clark[m]Sounds good I'll check back in after lunch00:33
clarkbtonyb: ok I'm around now02:05
tonybI'm looking at thew mirroring stuff02:05
tonybKinda thinking about what the ansible will look like02:06
tonybSIlly question, is there a way to tell zuul ... "ignore this change for now it isn't worth testing" ?02:07
clarkbyou can remove all the jobs from the job list02:08
clarkbbut other than that no02:08
clarkbthen basically revert the file back to its normal state when ready to get it CI'd02:08
clarkbI think what we want to do is update the base-test pre.yaml playbook to run the new role02:08
clarkband then iterate on that until we're confident it works reliably on the various platforms02:09
tonybYeah 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 instead02:09
clarkbya unfortunately we lose all of the speculative power of zuul in these trusted areas02:10
tonybkinda import-role ... \nwhen: zuul_mirrorinfo is defined 02:10
clarkbso we end up doing hacky things like copying roles and modifying them and testing with base-test02:10
tonybAhh okay02:11
clarkball of that is clunky but is the approach that seems to work best02:11
tonybI'm going to start with 'pip02:15
tonyb' as that's the easy one :)02:15
opendevreviewClark Boylan proposed opendev/system-config master: Update to Gitea 1.20
tonybANother 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 mirror03:34
tonybclarkb: 886993 is getting kinda ... long03:35
clarkbwe 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 things03:35
clarkbtonyb: 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 stuff03:36
clarkbI'm hoping they might fix the oauth2 stuff and we can trim that back out03:36
tonybclarkb: 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 role03:37
clarkbuse it?03:39
tonybclarkb: 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 situation03:39
tonybclarkb: 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/cloud03:41
tonyblocal testing before I publish etc03:41
clarkbah yup. Its totally fine to use for that purpose. More of a don't configure your productio nservers to use our mirrors03:42
tonybGot it :)03:43
clarkbI'm going to pop out now04:19
opendevreviewMerged openstack/project-config master: Add Intel Ethernet Operator app to StarlingX
*** jgwentworth is now known as melwitt16:18
corvus#status log deleted old zuul executor servers16:44
opendevstatuscorvus: finished logging16:44
ildikovHello 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
fungiildikov: yes, they about it a couple of weeks ago and we merged to fix it but may still need a gerrit restart for it to take effect18:13
fungier, they asked about it18:13
fungiit 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
fungii think it came up with starlingx/docs changes because those use the stx-docs project in lp18:14
ildikovfungi: ah, ok, got it18:16
ildikovthe examples I got pointed at were for different project teams, but they potentially fall under that same category18:16
ildikovfungi: is there a way to figure out if it's a Gerrit restart that's needed for that fix to take affect?18:18
ildikovor if there's something else in the background?18:18
fungii 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 image18:22
fungiand yeah, i'm almost certain that's it because we build and upload new gerrit images every time we merge a change to jeepyb18:23
ildikovfungi: ok, that makes sense, thanks for clarifying18:23
fungilast gerrit restart was on may 12, well before that revert change merged18:23
fungiso 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
ildikovI checked the LP examples and they were also well after the fix, so things seem to line up with your suspicion18:25
ildikovsounds 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 startup19:12
fungithat's a great point. i'll take another look at the gerrit update now19:14
fungias 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 past19:24
Clark[m]Maybe that is a good stopgap procedure for now19:25
fungifair. i guess actually quieting it would involve pausing zuul and blocking ssh/https access temporarily19:25
fungiwhich is probably worse than missing a queued task19:25
fungi#status log Set Gerrit's receive.rejectImplicitMerges option per
opendevstatusfungi: finished logging19:34
opendevreviewMerged opendev/system-config master: Enable receive.rejectImplicitMerges for Gerrit

Generated by 2.17.3 by Marius Gedminas - find it at!