Re: Building GCE images with bootstrap-vz

Hi,

On Mon, Feb 24, 2014 at 2:10 PM, Anders Ingemann <anders@ingemann.de> wrote:

> Do you suggest adding more generic plugin, with potential line in manifest with NTP server address?

Is NTP optional on GCE or is it a must have because of some other stuff?
If it is optional, I'd suggest a plugin as well. Just hack it together in a minimal way, you can always add options later on :-)

NTP as such is exactly as useful on GCE for keeping time in sync as it is in other virtualized environments, i.e. very. The strongest reason to change the server hostname inside GCE is for those instances where they don't have an external IP address, or otherwise choose not to allow the VM to access the internet as a customer security decision. Such instances can still reach the NTP server at metadata.google.internal since it's provided by the GCE environment itself.

> Here is the list of all tasks from non-Python GCE build-debian-cloud parts that I've omitted:

> 35-disable-ipv6

Might be useful to have in common, since AWS doesn't support it yet either.

In common sounds good, though we should remember that some virtualized environments do support IPv6, so both ways would be good to support.

p.s.: Try out the development branch. I've added quite a few fixes. Also: I think you might benefit from the minimize_size plugin using zerofree. It zeroes out unallocated disk space, which increases the effect of compression A LOT. I tested it on an almost barebones setup with ssh, sudo and nfs-client: (gzipped) 118 MB :-)

Neat! The shrink part of that plugin would be great to have work on raw disks as well, such as GCE / KVM / qemu / etc all use; when the build filesystem supports this, the fallocate call with FALLOC_FL_PUNCH_HOLE should do the trick.

Also, does the code start out with a sparse disk image? GNU truncate is one way to do this, which we use in the GCE build-debian-cloud logic. The standard dd command can also achieve the same effect. This achieves much of the benefit of after-the-fact sparsification, with the exception of disk space that is allocated then freed during the build. This should happen in all image builds that make raw disk images from scratch, since it's generally useful and widely portable across build filesystems/OSes even where zerofree or FALLOC_FL_PUNCH_HOLE is unavailable.

- Jimmy