Fedora @ Google Cloud

Colin Walters walters at verbum.org
Sun Jun 22 12:05:36 UTC 2014


On Wed, Jun 18, 2014, at 01:49 PM, Dennis Gilmore wrote:
>
> The issue is we are trying to build one image to run in all clouds, so
> cloud provider specific tools are out. 

I faced a similar problem with the images I am generating with ostree,
and what I ended up doing was producing a base image, and then
"postprocessing" it via libguestfs to enable/disable services.

So if we did decide to ship the GCE agent software, it would be possible
to produce one cloud image with both cloud-init and GCE agent, with
*both disabled by default* (note requires changing cloud-init package to
stop auto-enabling itself)

Then the script boils down to:

$ cp fedora-cloud.qcow2 fedora-cloud-standard.qcow2
$ guestmount /path/to/fedora-cloud-standard.qcow2 /mnt
$ systemctl --root=/mnt/ enable cloud-init.service
$ fusermount -u /mnt

$ cp fedora-cloud.qcow2 fedora-cloud-google.qcow2
$ guestmount /path/to/fedora-cloud-google.qcow2 /mnt
$ systemctl --root=/mnt/ enable google-daemon.service
$ fusermount -u /mnt

Each takes literally just a second or two to execute and can be easily
scripted on a rel-eng server (though I guess you'd want to wrap mock
around it).

FWIW the code I wrote is here:
https://github.com/projectatomic/rpm-ostree-toolbox/blob/master/src/js/builtins/postprocess_disk.js
I had to make custom code for rpm-ostree based images, but the concept
would work for mainline as well.
(An important but tricky part of this is ensuring the labels are correct
on newly generated files; see
https://www.redhat.com/archives/libguestfs/2014-May/msg00094.html .  I
also handle that specially with ostree).

> extend the functionality of
> cloud-init if you feel its useful. Ideally its something that can work
> in all providers.

All of the above said, I agree and would prefer investing in cloud-init,
even at the cost of the image deviating a bit from the "GCE standard". 
Any other opinions?


More information about the cloud mailing list