Thursday, 2022-07-14

clarkboh its the very grandparent change that complains00:00
clarkbI don'00:00
clarkber I don't understand why that change in particular would trip that check. Does the propose-updates job use that playbook maybe?00:00
clarkbor trigger on it? something like that is my best guess00:01
clarkboh you know what00:01
clarkbZuul had a change to check this stuff better before merging00:01
clarkbbefore it would fail when trying to run the job iirc00:01
clarkbbut now zuul can catch this stuff early. This may just be fallout from that. Before it would've failed to run the job at all. But now (since the upgrade over the weekend) we catch it when updating the config itself00:02
opendevreviewIan Wienand proposed openstack/project-config master: Remove publish-service-types-authority dependency  https://review.opendev.org/c/openstack/project-config/+/84976400:02
clarkbcorvus: ^ fyi I think we theorized this could happen but figured it was ok since things would've been broken previously00:02
clarkbDid that get a release note in zuul? If not we may want one00:02
*** dviroel|rover is now known as dviroel|out00:14
ianwlooks like we don't put a space next to the pin mark on the notice tweets00:25
ianwhttps://twitter.com/opendevinfra/status/154723306503813529900:25
ianwthis is triggering my whitespace sensibilities00:25
opendevreviewIan Wienand proposed opendev/statusbot master: twitter: ensure we have a space after the status icon  https://review.opendev.org/c/opendev/statusbot/+/84976600:27
opendevreviewMerged openstack/project-config master: Remove publish-service-types-authority dependency  https://review.opendev.org/c/openstack/project-config/+/84976400:31
ianwfungi/clarkb: https://review.opendev.org/q/topic:upload-pypi-api should be ready for review now, to switch the pypi uploads to api token.  everything stacks ontop of https://review.opendev.org/c/zuul/zuul-jobs/+/84958900:45
opendevreviewMerged opendev/statusbot master: twitter: ensure we have a space after the status icon  https://review.opendev.org/c/opendev/statusbot/+/84976600:49
*** ysandeep|out is now known as ysandeep02:46
opendevreviewMerged opendev/system-config master: Update Gitea to 1.16.9  https://review.opendev.org/c/opendev/system-config/+/84975404:07
opendevreviewIan Wienand proposed openstack/diskimage-builder master: Revert "containerfile: use focal for testing"  https://review.opendev.org/c/openstack/diskimage-builder/+/84927405:16
ianwinfra-prod-service-eavesdrop: timed_out06:03
ianwthat's a weird one06:03
ianwafaics, from the log file on bridge, that ran to completion06:05
ianwthis is not particularly uncommon :/ https://zuul.opendev.org/t/openstack/builds?job_name=infra-prod-service-eavesdrop&result=TIMED_OUT&skip=006:09
opendevreviewIan Wienand proposed opendev/system-config master: production-playbook logs : don't use ansible_date_time  https://review.opendev.org/c/opendev/system-config/+/84978406:27
opendevreviewIan Wienand proposed opendev/system-config master: production-playbook logs : move to post-run step  https://review.opendev.org/c/opendev/system-config/+/84978506:34
*** ysandeep is now known as ysandeep|afk06:46
mariosmorning folks anyone know whats up with gerrit getting 500 internal server error trying to post comments07:39
jm1in addition to marios: trying to do a "git review" on opendev projects causes an error "error: remote unpack failed: error No space left on device"07:39
jm1"fatal: Unpack error, check server log"07:40
gtemasame for me - can't push new changes07:48
ianwah, that's annoying, the disk is full07:49
ianwok, sorry about that, should be ok07:54
jm1ianw++ pushing reviews works again. thank you :)07:55
gtemathanks for prompt support ianw, works now07:55
ianw#status log freed up some space on gerrit partition review.opendev.org after full disk errors07:57
opendevstatusianw: finished logging07:57
mariosthanks ianw 08:04
*** mrunge_ is now known as mrunge09:12
opendevreviewJonathan Rosser proposed opendev/base-jobs master: Separate swift provider selection from the swift log upload task  https://review.opendev.org/c/opendev/base-jobs/+/84888109:21
*** soniya29|ruck is now known as soniya29|ruck|afk10:33
opendevreviewIan Wienand proposed openstack/diskimage-builder master: Revert "containerfile: use focal for testing"  https://review.opendev.org/c/openstack/diskimage-builder/+/84927410:55
*** soniya29|ruck|afk is now known as soniya29|ruck11:01
*** ysandeep|afk is now known as ysandeep11:05
*** dviroel__ is now known as dviroel|rover11:15
*** soniya29|ruck is now known as soniya29|ruck|afk11:27
opendevreviewMerged openstack/project-config master: Add a new openinfra/way project  https://review.opendev.org/c/openstack/project-config/+/84957612:13
*** ysandeep is now known as ysandeep|break12:38
*** soniya29|ruck|afk is now known as soniya29|ruck12:46
*** dasm|off is now known as dasm12:53
*** ysandeep|break is now known as ysandeep12:56
*** ysandeep is now known as ysandeep|afk13:01
opendevreviewMerged openstack/project-config master: Add openinfra/way to Zuul  https://review.opendev.org/c/openstack/project-config/+/84957714:54
corvus<clarkb> "Did that get a release note in..." <- I think we tried in https://zuul-ci.org/docs/zuul/latest/releasenotes.html#bug-fixes but maybe we didn't describe it 100%?14:58
clarkbcorvus: ya I think there is a third case which is "you may discover new errors when pushing chagnes to previously "happy" repos"14:59
corvusclarkb: i suspect our focus at the time was on in-repo configs of untrusted projects; but config projects may see more errors because they have lots of project stanzas.15:01
opendevreviewClark Boylan proposed opendev/system-config master: Fix system-config-run-review file triggers  https://review.opendev.org/c/opendev/system-config/+/84987915:59
opendevreviewClark Boylan proposed opendev/system-config master: DNM forcing test failure to hold test gerrit  https://review.opendev.org/c/opendev/system-config/+/84988015:59
*** ysandeep|afk is now known as ysandeep16:04
opendevreviewClark Boylan proposed opendev/system-config master: Explicitly disable large Gerrit disk caches  https://review.opendev.org/c/opendev/system-config/+/84988616:25
*** ysandeep is now known as ysandeep|out16:30
*** dviroel|rover is now known as dviroel|rover|brb16:35
*** dviroel|rover|brb is now known as dviroel|rover17:35
*** dasm is now known as Guest501317:59
*** Guest5013 is now known as dasm18:01
*** rlandy is now known as rlandy|biab19:36
clarkbinfra-root: Likely not complete yet but here is the bionic server upgrade listing with some thoughts on how we can appraoch them https://etherpad.opendev.org/p/opendev-bionic-server-upgrades19:39
clarkbfeel free to add entries or notes too19:39
*** rlandy|biab is now known as rlandy20:29
corvusclarkb: added notes about dns20:37
clarkbthanks just saw them20:38
ianwfungi / clarkb: could you have a look at https://review.opendev.org/q/project:opendev%252Fsystem-config+status:open+topic:log-timestamp; i think it will help diagnose some timeouts on the jobs i saw late yesterday 20:48
clarkbianw: yes20:55
clarkbianw: second change in that topic needs updating21:04
clarkb(details on the chagne itself)21:05
opendevreviewMerged opendev/system-config master: Fix system-config-run-review file triggers  https://review.opendev.org/c/opendev/system-config/+/84987921:06
*** dasm is now known as dasm|off21:23
ianwre 849886 seems a bit of deficiency in h2 if it can't clean itself up :/21:56
opendevreviewIan Wienand proposed opendev/system-config master: production-playbook logs : move to post-run step  https://review.opendev.org/c/opendev/system-config/+/84978521:58
ianwclarkb: ^ doh!, thanks :)21:58
*** dviroel|rover is now known as dviroel|rover|afk21:59
*** rlandy is now known as rlandy|bbl22:04
clarkbianw: ya according to upstream gerrit it is a known issue with h2 because h2 will only spend 200ms compacting before giving up (and that isn't long enough for the larger files)22:09
clarkbianw: fungi: I think 849886 is something we keep in our back pocket after we see if we can stabilize with larger disk.22:09
clarkbI think our next steps are: Delete the older of the two index backups currently in the filesystem (that should free another 14GB). Then either replace the cinder volume with a new larger one or add a second volume to increase the size of the lv then extend the ext4 fs on top of that. I think I have a slight preference for replacing the volume since fungi has done that quite a bit22:10
clarkbrecently and it seems to work well and is fewer moving parts22:10
clarkbBut then we monitor and see if we stabilize consumption on the larger disk and if not proceed iwth 84988622:11
ianwfor my own reference when i'm searching this conversation, the cache docs are22:11
ianwhttps://gerrit-documentation.storage.googleapis.com/Documentation/3.5.2/config-gerrit.html#cache_names22:11
ianware we sure that the storage from backup01 is the same type as the one attached to /home/gerrit2?22:12
clarkbBefore we can add mor edisk we need to free up the old backup server's cinder volumes so that our quota can be repurposed. Or we can ask mnaser kindly for a quota bump but it sounds like we are ok to clean up those cinder volumes22:12
ianwistr some discussion about about that22:13
clarkbthat == more quota or freeing up cinder volumes?22:13
ianwsorry, the storage type selected for /home/gerrit222:13
clarkbits currently an nvme ovlume right? I think that was chosen to match the old rax ssd volumetype as closely sa pssible22:14
clarkbconsidering the amount of disk io that gerrit does I think that is still warranted22:14
clarkbI marked 849886 WIP to make it more explicit that this is our fallback option22:20
clarkblooks like we have quota now after some pruning. I think that means ew can proceed with adding a newer bigger volume. fungi were you still interested in driving that since you've done a number of them recently ( and have a lot more familiarity with lvm than I do)22:26
clarkb/home/gerrit2/index.backup.1643061960 is the older of the two index backups on that filesystem and represents another 14GB that I think we can cleanup too. If you want to rm that before you migrate the data22:27
clarkb(its block level replication though right so not sure if that makes it go faster or not)22:27
clarkbI'm going to try and catch up on the pypi token changes now that we've got something of a plan for gerrit22:28
fungiyeah, i can add an nvme volume (hopefully our quota for that isn't separate), did we want to double or quadruple the size?22:29
clarkbI was thinking 1TB because we ideally also need room for index backups when we do project renames and server upgrades22:30
clarkbI think if we double things may still end up tight22:30
fungithat's fair, yeah22:35
ianwclarkb: i know you're still in catchup/firefight mode but https://review.opendev.org/q/topic:selfsigned-shared-ca is a stack that's also ready22:35
ianwhttps://review.opendev.org/c/opendev/system-config/+/845316 is tangentially related 22:35
clarkbianw: noted22:37
clarkbI just discovered that gerrit can show you git blame info by accident22:53
clarkbianw: left a couple of comments on the pypi token changes. The major one is on the last testing change (idea for making it more reliable without comments and commit dances23:22
ianwis it updating the version number with the unix timestamp and always uploading? :)  that was a thought i had yesterday23:23
clarkbyes23:24
clarkbusing sed in the repo t oset it23:24
ianwhaha i guess great minds think alike :)23:24
clarkbianw: looking at the CA topic briefly I wonder if this could be made more generic and put in zuul-jobs. Specifically the CA bits and maybe the "give me a cert" part. Then have our LE testing tie into that somehow23:34
clarkbbit hand wavy and I ddon't think we need to solve that here now. But something to ponder23:34
ianwmaybe if it would be useful for zuul/zuul-registry/etc?23:38
clarkbwell more generally I know that devstack also creates a CA (it probably can't farm that out to zuul jobs due to being expected to run locally too) so seems like something that is generally useful23:40
opendevreviewIan Wienand proposed zuul/zuul-jobs master: upload-pypi: always test upload  https://review.opendev.org/c/zuul/zuul-jobs/+/84990323:47

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