Bug #17687
ISO history: fix?
0%
Description
See Bug #17686 (parent task) for context, and Bug #17414 which was about slow networking in general when releasing.
This ticket is specifically about trying to fix the incredible performance issues we can get when it’s time to push data to the git-annex powered ISO history repository.
Assigning to Sysadmins for the time being.
Subtasks
History
#1 Updated by anonym 2020-05-06 12:56:50
One solution here is to ssh jenkins.lizard
locate the image and then import to isos.git
from there (after verifying them, of course). This is possible right now, with the caveat that you’d have to move your personal SSH key (the one you use for accessing isos.git
) there. That’s a no-no of course. :)
Instead, what if:
- we add a checkout of
isos.git
somewhere onjenkins.lizard
that all RMs have rw permissions to - we generate a new key SSH that I will refer to as K
- we give push rights for key K to the
isos.git
repo - we tell puppet to import key K for all RMs accounts on
jenkins.lizard
- we add instructions to
release_process.mdwn
so the history import is just a copy-paste job (including verifying the images first, droping the local copy from the Git annex after the import to save disk space, etc) - possibly instruct the TR to verify that the correct images was uploaded to the images history archive as well
One drawback is that all RMs then need access to jenkins.lizard
. ATM it seems kibi doesn’t, so that would be a necessary change. Note that any of our VMs that has access to Jenkins’ build artifacts will do, so if there is another VM with that access but that exposes less critical infra it could replace “jenkins.lizard
” above.
Thoughts?
#2 Updated by anonym 2020-05-06 12:58:41
- blocks Feature #16209: Core work: Foundations Team added
#3 Updated by CyrilBrulebois 2020-05-06 14:49:36
Right, I haven’t even tried to access jenkins.lizard yet.