vm building with veewee CI tuning notes

gistfile1.md

CPU

• 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

MEMORY

• introduced VEEWEE_MEMORY_SIZE to override the memory size

DISK I/O

• use SSD or memory
• created tmpfs and linked it to VIRTUALBOX_HOME

NETWORK I/O

• 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?

COMPILE TIME

• 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?

RANDOM THOUGHTS:

• 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

Could be possible to use a temp mounted disk image inside the VM as a local installation source, and thus limit network IO. You could maintain and update (rsync?) the image distro-mirror/repo separately.

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

• http://galvanite.blogspot.no/2011/07/linked-clones-in-virtualbox.html
• http://communities.vmware.com/message/2160849
• KVM qcow2 linked cloning might be possible too, although I don't know how fast that would be

Has anything come of using a squid proxy? I'm finding myself wanting something along these lines for building/testing/tweaking definitions.