Hi Oliver,The Google Compute Engine patch was submitted in http://bugs.debian.org/cgi-bin/bugreport.cgi?bug=725384 and made it into Debian experimental. Thomas Goirand very reasonably wanted someone to test the result of swapping that in and removing some of the Google integration scripts before adding it to Debian unstable, but those of us at Google have been too swamped to do it yet. (We've been working toward a lot of public launches and announcements, plus less obvious rapid changes, and all the relevant teams here are tiny but starting to grow. Yes we're hiring!)We haven't forgotten and were planning to return to it in upcoming months, but if you are interested in trying it out sooner, we'd love that. Tomasz Rybak just started working with our code, has successfully built a wheezy Compute Engine image with a small bug fixed, and is preparing to start work on bringing us forward into the Python world. In parallel, it would be great if you'd like to do cloud-init tests with the current code, to see which parts of the Google integration scripts can be removed or disabled in the presence of cloud-init, and which are outside cloud-init's scope and therefore should stay.Some background:The scripts which we preinstall are here: https://github.com/GoogleCloudPlatform/compute-image-packages - the README.md goes into more details on what the subdirectories are, how to contribute, etc. Out of the three subdirectories, google-startup-scripts has a lot of cloud-init overlap and a lot of non-overlap; google-daemon does a more comprehensive job of cloud-init's attempted account management but otherwise doesn't overlap; and gcimagebundle has none. Everything's shell or Python or a config file, no binary blobs, and all Apache-licensed free software. embed-kernel.sh is for users who are working with preview-era Compute Engine images and can be ignored.
The Compute Engine part of build-debian-cloud (on the shell-based master branch for now) installs these from an apt repository where we currently serve basic "drop these files in place, and run update-rc.d for the init script" style debs, and also two free-software command-line utilities (gcutil in a similar basic deb form, plus gsutil in /usr/local). (More proper packaging from Debian would be welcome for all of this and is very much something we want to fix in 2014. Overall we're getting closer to sending out a call for volunteers with a lot of ways to help, including this one.)
It's possible that part of our build-debian-cloud logic duplicates some of cloud-init and should be removed, but this is secondary.How cloud-init would change this:Within google-startup-scripts, probably the simplest way forward is to add a patch to disable the duplicated parts in a cloud-init environment, so that it works both with and without cloud-init. (One or two remnants of former broken cloud-init userdata support can still be found in the code, which should probably yield to cloud-init doing it right.)
This could be tested several different ways: by rebooting (not for first-boot-only actions), by deleting and re-adding the instance while preserving the disk, by making a new image with gcimagebundle, etc, by patching it at image build time in your local checkout of build-debian-cloud, etc. Once we merge and release a new set of packages (or a merged version gets proper Debian packaging), it would be sufficient to add (a version with our patch of) cloud-init to the list of packages to install on GCE, plus even more testing. :)
- JimmyOn Wed, Jan 15, 2014 at 10:52 PM, olivier sallou <olivier.sallou@gmail.com> wrote:
Hi,when I look at cloud-init doc, I do not see any Datasource for Azure and Google Compute, though I remember having seen some emails about Google compute.Are any of those available ? and if not, is there any reason, but a person to do it? :-)ThanksOlivier--gpg key id: 4096R/326D8438 (keyring.debian.org)Key fingerprint = 5FB4 6F83 D3B9 5204 6335 D26D 78DC 68DB 326D 8438
gpg key id: 4096R/326D8438 (keyring.debian.org)
Key fingerprint = 5FB4 6F83 D3B9 5204 6335 D26D 78DC 68DB 326D 8438