We are working on enabling cloud-init during the subiquity live session.
The motivation for this is to let users of systems with basic terminals complete the installation via SSH. However it also provides other interesting possibilities.
The default cloud.cfg in the live session by default will create a random password for the “installer” account. In other respects, little will change by default – the networking will try to dhcp on all interfaces, and the existing mechanism of configuring the network via ip= arguments will continue to work. But of course, having cloud-init around allows other possibilities such as using cloud-config snippets on the kernel command-line (
cc: proxy: some-proxy end-cc) or by providing a cloud-init data source (local or remote).
Having cloud-init running in the live session gives full flexibility to users to automatically do anything in the live-session one could possibly wish for. This led us to thinking that the ‘autoinstall’ config could be provided via cloud-config. Meaning, that one simply provides
autoinstall: in the user-data just like any other ephemeral configuration.
This would obsolete the section of the autoinstall design about providing the autoinstall file, as cloud-init supports a great deal of flexibility around how user-data is provided and merged.
The easiest meta-data source to provide is “NoCloud” which is documented at https://cloudinit.readthedocs.io/en/latest/topics/datasources/nocloud.html. The user-data files can be put on a filesystem with label CIDATA or served via http (supplying the url on the kernel command line). An minimal example of what the user-data might look like for a simple autoinstall would be:
#cloud-config autoinstall: version: 1 identity: username: user password: $crypted_pass