Thanks for looking at this!
I agree with most of your points and would normally agree with all of them. There are two where specific temporary circumstances apply:
On Feb 22, 2014 3:44 AM, "olivier sallou" <firstname.lastname@example.org> wrote:
> Best, of course, would be to get those packages directly in Debian instead of using Google mirror.
Agreed. Currently we are building those debs via crude internal-only hacks, but we want to move to proper packaging and get these into Debian.
For all of those packages except gcutil, we'd love pull requests to https://github.com/GoogleCloudPlatform/compute-image-packages - I'm also expecting to have more time to assist in March and April, but since that goes in waves, it's a great chance to get more non-Googlers involved.
All of these should be pretty straightforward and pretty dh-friendly, too. (Only real caveats: if you package the Upstart config file, realize it's been tested only on CentOS 6 and RHEL 6, where the OpenSSH server uses a different init script name than on Debian; and the systemd support has only been tested on SUSE.)
Regarding gcutil, we want to get the new Google Cloud SDK into Debian and switch to the gcutil integrated in that. Other Googlers will probably be the main Google-side partners on that packaging, though since they're less familiar with Debian or Linux packaging you can be sure they'll welcome involvement from the Debian community.
One or two related issues are being sorted out first; I'll then connect them with debian-cloud. Look for more soon when we're ready to start this.
My teammates and I will remain involved in the integration of Google Cloud SDK into bootstrap-vz and the resulting GCE images.
> This task downloads files from a remote location (at Google). Should not the gsutil code source provided within bootstrap-vz waiting for an official Debian package ?
> With a download at each image creation, we do not know the version of gsutil downloaded files nor, in case of remote modifications, if image remains "stable" across builds.
The proper medium-term solution for this is also Cloud SDK; although the gsutil website doesn't yet point people to that, when you install Cloud SDK it does include an integrated version of gsutil.
Currently we've been taking care to ensure that images include both the newest gsutil and the newest gcutil as of build time, and then running extended test suites to have confidence in the results. That download URL always points to the newest gsutil tarball, and we've updated the gcutil deb in our repository before building publishable images if it's gone stale.
We certainly don't want to stop running tests, but we agree it will probably make sense to pull the latest Debian backports versions of the relevant Cloud SDK rather than pull directly from Google distribution methods. (Can't rely on pure stable for these since they're not in wheezy. We can configure apt_preferences to minimize backports use as our backports-kernel-enabled images currently do, or offer images where we remove the backports repository partway through the build as build-debian-cloud currently does with Google's repository.)
This should ideally include frequent enough updates to the backports versions of Cloud SDK, but that certainly doesn't have to include every release. Google will probably offer auto-built debs in a Google-run repository for those who always want our very latest code, and possibly parallel variant convenience images with clear descriptions (not branded as pure Debian), but it won't be in any official Debian images by default.
I realize the dislike of packages which are not yet in Debian; we agree it's (multiple) bugs to be fixed. Bear with us. Working together across both Google and debian-cloud, I hope this will be a mere memory by the time we meet at DebConf. :)
>> Best regards.
>> Tomasz Rybak GPG/PGP key ID: 2AD5 9860
>> Fingerprint A481 824E 7DD3 9C0E C40A 488E C654 FB33 2AD5 9860
> gpg key id: 4096R/326D8438 (keyring.debian.org)
> Key fingerprint = 5FB4 6F83 D3B9 5204 6335 D26D 78DC 68DB 326D 8438