Thursday, 2024-03-28

tkajinamFailed to download packages: kernel-devel-5.14.0-432.el9.x86_64: Cannot download, all mirrors were already tried without success09:20
tkajinamhmm09:20
tkajinamI guess it takes some time until the new kernel version is pulled to base cs9 image ?09:20
jcapitao[m]RDO is also facing issues when pulling packages from opendev AFS 09:21
fricklerthe centos upstream we have been syncing from seems to be pretty unstable, had a similar issue yesterday already09:25
apevechmm it was supposed to be primary source, if we have logs let's report to https://pagure.io/centos-infra/issues09:29
jcapitao[m]I see it syncs every 6h09:29
tkajinamI can't open the package list of c9s appstream in mirror but I'm suspecting that a few packages are not synced properly there09:32
jcapitao[m]next iteration will be at 12 noon UTC09:33
apeveclog is https://static.opendev.org/mirror/logs/rsync-mirrors/centos-stream.log right?09:34
jcapitao[m]I'm using https://mirror.dfw.rax.opendev.org/logs/ which is another mirror09:36
jcapitao[m]but it's the same right09:36
jcapitao[m]there is also https://files.openstack.org/mirror/logs/09:36
jcapitao[m]it's all the same content09:37
tkajinamok so -432 of kernel-devel does not exist in https://mirror.dfw.rax.opendev.org/centos-stream/9-stream/AppStream/x86_64/os/Packages/09:42
frickleryes, the logs are also stored in AFS, so should be consistent everywhere09:42
tkajinamwhile we have -432 of kernel exists in https://mirror.dfw.rax.opendev.org/centos-stream/9-stream/BaseOS/x86_64/os/Packages/09:43
tkajinamhmm. the log indicates that package was in the incremental diff list detected by rsync...09:46
jcapitao[m]so few packages got lost in last sync. I have same issue with podman-5.0.0-1.el9.x86_64.rpm09:47
apevecyeah, seems to be incomplete sync, repodata in AFS references RPM packages which are not in AFS e.g. crun-1.14.409:47
apevecoh you mean they were there then deleted ?09:47
tkajinamdeleting AppStream/x86_64/os/Packages/kernel-devel-5.14.0-432.el9.x86_64.rpm09:49
tkajinamI'm still confused by the log (mainly because it's huge) but it might be possible that the package was missing from the upstream mirror so was removed09:50
tkajinamAppStream/x86_64/os/Packages/.~tmp~/kernel-devel-5.14.0-432.el9.x86_64.rpm09:51
tkajinamthough this one comes later.09:51
jcapitao[m]same with deleting AppStream/x86_64/os/Packages/podman-5.0.0-1.el9.x86_64.rpm09:53
fricklerthe ".~tmp~" indicates that the sync happened while upstream was itself syncing from some other source?09:54
jcapitao[m]I think you're right tkajinam it seems those files were not available on sender side during the rsync operation09:54
tkajinamok... if these packages haven't been yanked then we can probably wait for the next sync10:00
apevecamoralej_: jcapitao: might be still worth to open centos-infra ticket to check what happened on centos primary rsync ?10:55
jcapitao[m]yes FTR I'll open one after next iteration and will put some logs11:04
jcapitao[m]apevec tkajinam : FYI I opened an issue on centos-infra side https://pagure.io/centos-infra/issue/138414:08
apevecthanks Joel!14:12
Adam_kinghello14:26
Adam_kingi'm new here. I don't really understand how this site works14:26
Adam_kingI'm trying to learn how to contribute14:27
corvus1i have approved https://review.opendev.org/914412 which should cause us to delete some unused nodepool image files.  i'll check on it later to make sure it works as expected.15:01
clarkbcorvus1: thanks!15:07
clarkblooks like Adam_king only stuck around for a handful fo minutes :/15:07
clarkbjcapitao[m]: tkajinam apevec as discussed the other day the primary options available to us are either to have upstream update the mirror in a safe order (generally you add new packages then update indexes then remove packages so that regardless of when you sync you're get a working state), we update our sync script to either use some expected tooling we are using or update it to15:09
clarkbverify state before publishing within afs (this is how reprepro works with debuntu, it does a verification step and if that fails we don't publish), or switch to a different upstream that might be more stable15:09
opendevreviewMerged openstack/project-config master: Enable nodepool delete after upload option  https://review.opendev.org/c/openstack/project-config/+/91441215:10
corvus1the good news is that i don't think the builders are deleting too many files; the bad news is i don't think they're deleting any.16:07
corvus1clarkb: oh i think the diskimage parent system is a little more manual than we would like.  i'm pretty sure that value didn't get propagated to children16:10
corvus1rather than update the config to be explicit, i'll fix that in the builder16:11
clarkbcorvus1: oh interesting so the config wasn't applied to any of the images because it is only on an abstract definition16:23
corvus1yep; found/fixed the issue in https://review.opendev.org/91465816:25
corvus1the format list was likely inherited, but not the enable flag16:26
fungijust checking in for a few minutes while i have working internet access, i'm still going to be mostly afk through the weekend16:28
clarkbfungi: not a whole lot going on. We could do the gitea 1.21.10 upgrade if people are brave but I don't think it is urgent. Probably not a bad thing to be somewhat slushy right now anyway with the openstack release coming up16:30
clarkbI've got paperwork things I should be doing too. The universe is conspiring to make that happen16:30
clarkbfungi: I think the only thing that came up with centos stream synced a bad mirror state again16:30
clarkbtwice in ~2-3 days16:30
fungiclarkb: TheJulia: JayF: if it's not clear, devstack doesn't take its target branch directly from a zuul var because certain jobs may want to run devstack with a different branch than what triggered it (grenade for example)16:32
clarkbfungi: yup (though we just discovered grenade doesn't do that properly for reasons)16:33
fungioh wow, even better16:33
clarkbfungi: https://opendev.org/openstack/grenade/src/branch/stable/zed/.zuul.yaml#L381-L407 this zed job config applies to all the stable/202* branches and then sets wallaby as the old branch16:34
* TheJulia tries to come up with a nice and appropriately sarcastic reply16:34
fungidevstack backward-compat jobs for some non-branching libs/clients may also run devstack for stable branches, can't recall if we still have any of those16:35
fungithough that may be done with branch overrides these days too16:36
TheJuliafungi: I think I got what I was looking at yesterday sorted, but it is good to know it is never simple :)16:41
opendevreviewJeremy Stanley proposed openstack/project-config master: Temporarily remove release docs semaphores  https://review.opendev.org/c/openstack/project-config/+/91468817:48
opendevreviewJeremy Stanley proposed openstack/project-config master: Revert "Temporarily remove release docs semaphores"  https://review.opendev.org/c/openstack/project-config/+/91468917:48
corvus1fungi: out of curiosity, what is the critical section for a release job semaphore?  is it just the copy, or is it the whole build?17:53
corvus1(i mean, in theory, not in implementation)17:53
corvus1(obvs the current implementation is the whole job)17:53
corvus1clarkb: fix merged; and builder just restarted18:07
corvus1https://paste.opendev.org/show/bGQp4jJHenbNlpO3MTUK/18:08
corvus1that looks correct to me18:08
corvus1still see qcow2 files for everything18:08
corvus1and i don't see any associated error messages; so i think everything looks good18:09
fricklercorvus1: iiuc it should be only the copy step18:18
corvus1then it may be worth looking into a playbook semaphore (and ensuring the copy is in its own playbook to minimize the critical section time).  might be fast enough you could leave the semaphores in place during release.18:20
clarkbya it is the copy step and it doesn't actually result in true issues but job errors can occur that are benign18:29
clarkbbasically resync gets mad that tmp files move around under it and reports failure but everything copies properly18:29
opendevreviewAlan Pevec proposed opendev/system-config master: Add AFS mirror update logs location  https://review.opendev.org/c/opendev/system-config/+/91186920:59
fungicorvus1: to clarify, if changes merge for or releases are tagged for different branches of the same project, release notes publication rsyncs occurring in parallel for them can either step on one another (one trying to remove the other's tempfiles) or complete out of order (leading to missing content until the next run for any branch of that project)23:39
fungifor the releases site, it's multiple release requests merging at the same time causing similar issues for publication of the releases.openstack.org site23:40
fungiit would be good to look into alternative solutions to avoid those collisions without resorting to serializing across every project (ephemeral per-project semaphores would do the trick in the release notes case, while a supercedent pipeline manager might be good for release docs)23:43
fungibut nobody's found the time yet23:43

Generated by irclog2html.py 2.17.3 by Marius Gedminas - find it at https://mg.pov.lt/irclog2html/!