- OK - introduced VEEWEE_CPU_COUNT to override the number of cpus
problem(s):
- multiple CPU's don't get passed to compiles so only CPU is busy
- introduced VEEWEE_MEMORY_SIZE to override the memory size
- use SSD or memory
- created tmpfs and linked it to VIRTUALBOX_HOME
- use squid proxy as (transparent) proxy
problem(s):
-
it's not yet transparent as the default is to use the NAT interface which doesn't seem to work with iptables PREROUTING?
-
need to pass http_proxy , HTTP_PROXY to all postinstall scripts
-
maybe we can pass it via ENV vars into the ssh session?
-
OS mirrors get selected randomly so will not get cached
-
proxy params needs to be passed to kickstart files , maybe by using ERB postinstalls?
- instead of compiling ruby/rvm etc.., turn it into a package with fpm or so?
- chef omnibus installer installs it's own ruby in /opt nicely , how about puppet ? especially for older platforms?
-
might be useful to snapshot after OS install to reuse the base part to create boxes for cfengine, puppet, chef boxes?
-
maybe we need to skip config mgmt all together as it can be done with script provisioners before config mgmt?
-
better to use multiple machines vs 1 big machine for parallel creation
-
kvm & virtualbox can't live together, how to best integrated in the builds on the same machine?
-
still need to move bento structure into veewee templates , but do symlinks work on windows?
-
replace cucumber with rspec to have fewer dependencies
No, scratch that. While in the gym(!) I thought it through again and I think I like your first 'random thought' the best: Reuse each base part. I'd even go further and say that only one single base build would be needed per OS variant - you'd need to standardize kickstarts/preseeds then but the gains are worth it IMO.
To take that further, to reduce compile time you could do all the postinstall.sh++ stuff per variant, based off a linked clone where the differential file would be in tmpfs or similar until exported