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