Closed Bug 1124420 Opened 9 years ago Closed 9 years ago

move run_l10n_sync.sh off github-sync4.dmz.scl3

Categories

(Developer Services :: General, task)

Product:
Developer Services
Component:
General
Type:
task
Priority:
Not set
Severity:
normal

Tracking

(Not tracked)

Status:
RESOLVED FIXED

People

(Reporter: hwine, Assigned: hwine)

References

Details

(Whiteboard: [re-vcs-sync]) 

Need to find a new home for this job.

Obvious candidates include:
 - interim move onto github-sync3
 - AWS
Looks like 5GB needed:
[vcs2vcs@github-sync4.dmz.scl3 ~]$ du -csh *
24K	bin
4.4G	vcs_sync
4.4G	total

ni :pete - how much headroom do we need above the 4.4G currently used "at rest"?
Flags: needinfo?(pmoore)
Looks like if we fail a staging clone, we blow it away before recloning, rather than parking:
http://hg.mozilla.org/build/mozharness/file/af1461521190/scripts/vcs-sync/vcs_sync.py#l353

Growth of our repositories as new commits / repos are added over time, and potential refactorings or new functionality will draw more demands on disk space.

Therefore I would say lets make sure we have an absolute minimum of a further 5GB headroom to allow our repos to double in size over time. 10-20GB headroom would be better if possible, e.g. often useful when troubleshooting, making temporary backups for later inspection during a recovery operation, or future refactorings/features. Currently we have 54GB free on github-sync4.
Flags: needinfo?(pmoore)
This is now running from dev-services aws instance.
Assignee: nobody → hwine
Status: NEW → RESOLVED
Closed: 9 years ago
Resolution: --- → FIXED
You need to log in before you can comment on or make changes to this bug.