(In reply to Rok Garbas [:garbas] from comment #2) > :aki I assume binary transparency is not planned to be migrated since it is not currently in use, correct? +1 > :aki also can you provide an ordered list (by your opinion) how we should tackle the scriptworkers. you are much more familiar of how complex they are in terms of dependency on tree. script | urgency | status | notes ------ | ------- | ------ | ----- pushsnap | high | not done | coordinate with jlorenzo. this will be ubuntu and will allow us to get rid of hacks signing | med | not done | need netflows to signing servers, fw updates, ip allowlist updates beetmover | med | not done | this will use a lot of network round-tripping to s3; watch this for bandwidth and $$ addon | | not done | this needs some scaling, and access to amo. pushapk | | not done | talks to gplay. we can probably get away with a single prod instance tree | | not done | this needs write/flows to hg.m.o, could possibly go over internet bouncer | | not done | talks to bouncer - needs netflows and fw? updates balrog | | not done | py2 script. we may want to upgrade to py3 before we migrate? We need netflows to the balrog admin api Pushsnap scriptworker would be my candidate for highest priority, since aiui the current setup is one big hack to get an ubuntu tool to run on centos. Docker (moving away from puppet) will allow us to run on ubuntu or debian. I think the signing and beetmover scriptworekrs may be on the trickier side because they're in heavy use. They will create a lot of network traffic between GCP and mdc{1,2} and/or s3, and the signing scriptworkers will require netflows and an allowlisted IP range. But agreed, we have scaling issues there, and moving them will be a big win. Balrog scriptworker is on py2. We could move it as py2 with a py3 scriptworker (two separate virtualenvs), or we could upgrade it to py3 before GCP. The other four are relatively straightforward, and can be done at any point.
Bug 1533337 Comment 4 Edit History
Note: The actual edited comment in the bug view page will always show the original commenter’s name and original timestamp.
(In reply to Rok Garbas [:garbas] from comment #2) > :aki I assume binary transparency is not planned to be migrated since it is not currently in use, correct? +1 > :aki also can you provide an ordered list (by your opinion) how we should tackle the scriptworkers. you are much more familiar of how complex they are in terms of dependency on tree. script | urgency | status | notes ------ | ------- | ------ | ----- pushsnap | high | not done | coordinate with jlorenzo. this will be ubuntu and will allow us to get rid of hacks signing | med | not done | need netflows to signing servers, fw updates, ip allowlist updates beetmover | med | not done | this will use a lot of network round-tripping to s3; watch this for bandwidth and $$ addon | | not done | this needs some scaling, and access to amo. pushapk | | not done | talks to gplay. we can probably get away with a single prod instance tree | | not done | this needs write/flows to hg.m.o, could possibly go over internet bouncer | | not done | talks to bouncer - needs netflows and fw? updates balrog | | not done | py2 script. we may want to upgrade to py3 before we migrate? We need netflows to the balrog admin api Pushsnap scriptworker would be my candidate for highest priority, since aiui the current setup is one big hack to get an ubuntu tool to run on centos. Docker (moving away from puppet) will allow us to run on ubuntu or debian. I think the signing and beetmover scriptworkers may be on the trickier side because they're in heavy use. They will create a lot of network traffic between GCP and mdc{1,2} and/or s3, and the signing scriptworkers will require netflows and an allowlisted IP range. But agreed, we have scaling issues there, and moving them will be a big win. Balrog scriptworker is on py2. We could move it as py2 with a py3 scriptworker (two separate virtualenvs), or we could upgrade it to py3 before GCP. The other four are relatively straightforward, and can be done at any point.