[Date Prev][Date Next] [Thread Prev][Thread Next] [Date Index] [Thread Index]

Re: Debian images for Google Compute Engine


On Wed, Apr 17, 2013 at 9:01 PM, Jimmy Kaplowitz <jimmy@debian.org> wrote:
> Sure. Right now what we have published is not images themselves, but tools for
> anyone to make their own. While we have of course built images internally and
> done testing, we would love for Debian to be the provider of official Debian
> images in Google Compute Engine. Publishing those images can be done by anyone
> we add to the debian-cloud project and does not need to be done by Googlers.

I've now uploaded two images to the debian-cloud project:

$ gcutil --project=debian-cloud listimages
|          name           | description |         creation-time
 |                    kernel                    | deprecation |
| debian-squeeze-20130418 |             |
2013-04-18T17:38:33.408-07:00 |
projects/google/global/kernels/gce-v20130325 |             |
| debian-wheezy-20130418  |             |
2013-04-18T19:12:31.887-07:00 |
projects/google/global/kernels/gce-v20130325 |             |

That project's images, unlike the debian-cloud-experiments project,
should be usable
from any Google Compute Engine project by passing the
--image=projects/debian-cloud/global/images/<image name> option to
gcutil addimage.

Feel free to try this out if you have Google Compute Engine space or
email David and
me with your plans and Google account info if you need access to help.
Of course,
nothing about the code is specific to that project and anyone can use
it to build and
upload to any Google Compute Engine project.

Our github fork (and the corresponding pull request) have been updated with
miscellaneous fixes and robustness improvements. The main substantive changes
are that --volume-size 10 is now the default for Google Compute Engine
builds, without
affecting other builds, and that all builds remove /etc/resolv.conf
before assembling
the image so as not to include build system info. Also, failed Google
Compute Engine
builds now tear down their loopback mounts more reliably, but leave
the temporary
workspace around to help in debugging the failure.

Anders, feel free to review and merge whenever you're ready. One to-do
item worth
mentioning: I didn't update the README.md for the rename and broader scope.

- Jimmy

Reply to: