Add cloud-init for gce images

[vitaminmoo]

There doesn't appear to be an easily locatable documented reason that the GCE official Debian images don't install and configure cloud-init. This causes the GCE documentation on the user-data metadata to not be accurate.

This change makes the GCE images function with #cloud-config format user-data.

The negative impact of this is that cloud-init will make a few changes on first boot, even if the user did not specify user-data metadata. This appears to be standard and ok in the ec2 and oracle manifests, though. The official GCE Ubuntu images also appear to create an ubuntu user on first boot, so it seems like there's parity.

The cloud_init plugin options are burgled from the most common form in the ec2 and oracle manifests, which is effectively no config other than setting a username.

I've set the username to what the default is in the Debian cloud-init package to avoid making arbitrary decisions that don't matter. If I could disable the default user section as it is in the COS cloud.cfg, I'd prefer that, but as is the cloud_init plugin is not particularly flexible, and rewriting it to be seems like overkill.

[andsens]

@zmarano, any comments?

[zmarano]

Please do not add cloud-init to the official GCE Debian manifests. It conflicts with our own software and is not the expected behavior at this point for GCE default Debian images. You are more than welcome to add cloud-init to your own instance or images but behaviors will be duplicated and your mileage may vary. If you are interested in more details about why we do not, this was captured in the notes from the cloud-init summit from 2017.

[andsens]

Alright, closing.

[vitaminmoo]

@zmarano - Can you confirm or destroy my understanding for the record?

• GCE default Debian images only support shebang-style startup scripts, and purposefully do not support #cloud-config based ones via cloud-init, differing from Container Optimized OS on GCE, and the GCE default Ubuntu images (which admittedly appear to be maintained by Canonical)?
• GCE employee presence at the 2017 cloud-init summit does not indicate support for cloud-init in GCE? I'm not super clear on what portion of the notes that were linked in the cloud-init summit page are relevant if cloud-init is not on GCE Debian at all

[zmarano]

@vitaminmoo

• Correct, startup scripts are exactly that. This is not the same thing as cloud-init however which tries to do a lot more that just run whatever arbitrary script you want to run.
• The background on the summit is that we hosted it with Canonical for the greater cloud-init community. While we don't use cloud-init by default in GCE, Ubuntu on GCE does. From our point of view, the use of cloud-init is up to the distribution in question or the user and is not necessary or actually relevant for GCE platform integration to work with any given guest OS. Debian has not standardized on cloud-init for any purpose and therefore we have no intention of making it default in Debian.

The GCE Linux guest software we employ does a handful of the same things cloud-init does but also a whole lot more that cloud-init cannot do (primarily instance life cycle operations based on metadata).

I don't want to rehash the cloud-init summit here. However the basic reasons we don't depend on cloud-init for GCE are:

• It is only boot time initialization and has no facility for long running processes or shutdown events. It therefore does not handle most of the use cases our own software does.
• It conflicts with our user login story which does differ from other cloud platforms.
• It adds considerable time to instance boot (on average 5 seconds without additional modules).
• It has a large graph of dependencies that we do not wish to maintain in base images, Debian being one of the most bare bones images there is.
• It is not consistently maintained in every distribution (or in some at all) and versions and features vary wildly.