[virt-tools-list] virt-install and cloud-init, feedback wanted

[Cole Robinson]

On 11/21/19 10:49 AM, Ryan Harper wrote:
> * Cole Robinson <crobinso at redhat.com> [2019-11-20 17:48]:
>> Hi all. The purpose of this mail is to get some feedback on pending
>> cloud-init support in virt-install. If you're on the CC list here, I
>> either pulled your email from a cloud-init discussion on the the
>> virt-tools-list mailing list, or from the CC list of this virt-install bug:
> 
> Hi Cole,
> 
> Thanks for starting this thread.  I'm a maintainer for cloud-init
> upstream[1], happy to help answer questions and provide some suggestions
> on virt-install cloud-init support.
> 

Thanks for the feedback Ryan! Responding with a slimmed CC list

>> * user-data=/PATH/TO/user-data: ignore all other options and copy this
>> file to the .iso as user-data
> 
> You may be interested in allowing users to specify a meta-data file
> as well; the meta-data file is used for setting things like the
> instance-id, hostname and network-config[3].
> 

Sounds good. I added `--cloud-init meta-data=/PATH/TO/FILE` support to
the upstream branch now.

>>
>> One more point: my main interaction with cloud-init has historically
>> been by grabbing a Fedora/RHEL cloud image, passing it to
>> virt-install/virt-manager, and watching the boot hang, because there's
>> no data provider and cloud-init times out talking to the network, and
>> then I can't log in. I expect many people have hit this issue before.
>> I've always worked around this by using 'virt-customize' to disable
>> cloud-init and reset the root password. That's about the extent of my
>> usage here, which is broadly why the bare `--cloud-init` is the way it was.
> 
> For some time now, cloud-init uses a systemd-generator to detect[4] on 
> which platform it is running and determine if user-data or config
> has been provided and if so, enabling the cloud-init service, other
> wise it stays disabled.  Your experience above is the primary reason
> for this feature as now booting a cloud image without any user-data
> should not mean the image hangs during boot.
> 
> The feature has been around since 2017, cloud-init 17.1 and newer
> support this feature.
>

Interesting. I tested with this ubuntu image:
https://cloud-images.ubuntu.com/eoan/current/eoan-server-cloudimg-amd64.img

And indeed, seems like it drops quite quickly to a login prompt when no
cloudinit data is passed in. And --cloud-init seems to work as expected.

So I wonder, why does Fedora 31 images still seem to hang, waiting for
network timeout? Is this something that needs to be explicitly enabled
in the disk image cloud.cfg?

FWIW here's the fedora 31 cloud.cfg: https://pastebin.com/1cVCAgqE

Thanks,
Cole