Yes, I saw that you were the author. Thanks for contributing that! :-) I'm not sure from this thread exactly who's going to do what work here, but I am certainly willing to chip in on the cloud-init work to make the GCE functionality closer to what a typical GCE user might expect. Andy On Mon, Jun 23, 2014 at 11:04 AM, Vaidas Jablonskis <jablonskis@xxxxxxxxx> wrote: > I wrote cloud-init support for GCE (it is upstream already), so let me know > if you need any help. > > > On 23 June 2014 15:50, Andy Grimm <agrimm@xxxxxxxxx> wrote: >> >> On Sun, Jun 22, 2014 at 2:27 PM, Dennis Gilmore <dennis@xxxxxxxx> wrote: >> > -----BEGIN PGP SIGNED MESSAGE----- >> > Hash: SHA1 >> > >> > On Sun, 22 Jun 2014 05:05:36 -0700 >> > Colin Walters <walters@xxxxxxxxxx> wrote: >> > >> >> 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). >> > It may not take long but its not an option. for a few reasons. >> > >> > 1) the image is intended to be just ran without tweaks >> > 2) we publish the image on the mirrors and anyone using them will have >> > to tweak it before using. which breaks at least openstack. you can >> > point it at a mirror and it will pull in the cloud image and it just >> > works. >> > 3) it means having two systems installed in the image along with any >> > unique deps. We are trying to make the base as small and unbloated as >> > possible. >> > >> > >> >> > 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? >> > >> > I strongly believe we need one way to do it. now having a hook to say >> > start an extra service when it detects its being run in GCE i wouldn't >> > object to. assuming that service is not huge. >> > >> >> This is very possible and should not be much work. cloud-init already >> is smart enough to determine it's on GCE and use the GCE data source >> to grab data from the metadata service. It's been a while since I've >> dug into the cloud-init code, but it should be trivial write some >> special metadata if the GCE datasource is active, and then have a >> config module that starts services if those special metadata bits are >> present (might mean writing to dbus or something to do it the "right" >> way from systemd's perspective.) >> >> Andy >> _______________________________________________ >> cloud mailing list >> cloud@xxxxxxxxxxxxxxxxxxxxxxx >> https://admin.fedoraproject.org/mailman/listinfo/cloud >> Fedora Code of Conduct: http://fedoraproject.org/code-of-conduct > > > > > -- > Vaidas Jablonskis > > _______________________________________________ > cloud mailing list > cloud@xxxxxxxxxxxxxxxxxxxxxxx > https://admin.fedoraproject.org/mailman/listinfo/cloud > Fedora Code of Conduct: http://fedoraproject.org/code-of-conduct > _______________________________________________ cloud mailing list cloud@xxxxxxxxxxxxxxxxxxxxxxx https://admin.fedoraproject.org/mailman/listinfo/cloud Fedora Code of Conduct: http://fedoraproject.org/code-of-conduct
