Fedora @ Google Cloud

Vaidas Jablonskis jablonskis at gmail.com
Mon Jun 23 15:04:36 UTC 2014


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 at gmail.com> wrote:

> On Sun, Jun 22, 2014 at 2:27 PM, Dennis Gilmore <dennis at ausil.us> wrote:
> > -----BEGIN PGP SIGNED MESSAGE-----
> > Hash: SHA1
> >
> > On Sun, 22 Jun 2014 05:05:36 -0700
> > Colin Walters <walters at verbum.org> 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 at lists.fedoraproject.org
> https://admin.fedoraproject.org/mailman/listinfo/cloud
> Fedora Code of Conduct: http://fedoraproject.org/code-of-conduct
>



-- 
Vaidas Jablonskis
-------------- next part --------------
An HTML attachment was scrubbed...
URL: <http://lists.fedoraproject.org/pipermail/cloud/attachments/20140623/05609589/attachment.html>


More information about the cloud mailing list