[virt-tools-list] virt-install and cloud-init, feedback wanted
Ryan Harper
ryan.harper at canonical.com
Fri Nov 22 16:02:34 UTC 2019
On Thu, Nov 21, 2019 at 5:21 PM Cole Robinson <crobinso at redhat.com> wrote:
> 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
>
> > 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?
>
It's likely a package build/install issue. There was a recent fix for
ensuring the path to ds-identify was correct on RedHat installs
https://bugs.launchpad.net/cloud-init/+bug/1833264
Ryan
-------------- next part --------------
An HTML attachment was scrubbed...
URL: <http://listman.redhat.com/archives/virt-tools-list/attachments/20191122/e58d8446/attachment.htm>
More information about the virt-tools-list
mailing list