Hello,
I would like to schedule migration for Friday next week, July 4. If you have any concerns, please let me know.
I also didn't receive any response regarding disk space concerns raised in the original mail (quoted below). Since then, I faced yet another with having so many jobs - it now takes quite a while to migrate them for any changes. So, my plan remains to stick with the current disk space, and then discuss and schedule cleaning of historical release builds.
If you don't agree with this tentative direction, and would rather see disk space (and maintenance effort) growing, please speak up soon.
Milo, please approve this plan and schedule otherwise if you see it ok.
Thanks, Paul
On Thu, 12 Jun 2014 22:02:56 +0300 Paul Sokolovsky Paul.Sokolovsky@linaro.org wrote:
Hello,
We're finishing migration of ci.linaro.org to the latest Ubuntu LTS release (14.04). android-build.linaro.org is next in queue. I guess, it makes sense to plan migration for the same time window as ci.l.o - past-release, first week of July. But maybe Android team has special plans or suggestions, so please let us know.
This would also be good time to discuss any changes or additional requirements for the migration. Actually, just today Fathi drew my attention to the fact that there were less 5% free on a-b jobs partition. Looking forward to upcoming migration, I did thorough clean up - we now back to 11% free, and that's actually 55Gb. I also did analysis of growth rate, and my calculations give below 7Gb/year. I hope that's not surprising - most builds we produce, also expire soon, so only growing residue is actually release builds.
So, based on this analysis, we should be fine for next couple of years. You're free to disagree of course. Then I can propose 2 solutions:
- Reconsider how 500Gb there is used. What suggests of such approach
is example, ci.linaro.org, which has a lot of jobs, but of whose 300Gb, 60% are free. That's apparently because it uses much more aggressive expiration policies - for example, unneeded jobs there are actually deleted. Applying that idea to a-b, the build/CI server, do we really need to host old historical releases there, if their official place is https://releases.linaro.org anyway? I guess, that's Fathi call too.
- If we don't want to change retention policies, and don't trust
small growth rate figure either, then increasing disk space is the obvious choice. But I'd say extra 100Gb would really be enough for foreseeable future - having too big a disk means more money (include back up cost), more time when you need back up soon, more fsck time, etc., etc.
I don't think there's much more to vary with this migration between new Jenkins version (implied) and disk space, but if somebody knows other issues which would be nice to fix, let us know (but again, talk is just about Jenkins master, not slaves or something else).
Thanks, Paul
Linaro.org | Open source software for ARM SoCs Follow Linaro: http://www.facebook.com/pages/Linaro http://twitter.com/#%21/linaroorg - http://www.linaro.org/linaro-blog