[06:37] just stumbled over https://github.com/virt-manager/virt-manager/commits/cloudinit [06:37] is that known or something you want to help with? [10:34] blackboxsw: for the record: I built and booted an Eoan template with 19.2-13-g2f3bb764-0ubuntu1 on our preproduction environment, and all seems well :) [13:33] tribaal: \o/ [13:36] cpaelzer__: I'm not aware of it, but it looks cool! What help could we offer? [13:36] (If you know!) [13:45] I guess we're ready to have Eoan available on day one :P === cpaelzer__ is now known as cpaelzer [14:33] Odd_Bloke: I don't know what they work on or woudl need right now [14:33] I just have seen the branch while cloning virt-manager for a fix [14:33] and wondered if that is part of a community activity that you'd know of [14:33] interesting ... [14:34] waiting if rharper doesn't know it either ... [14:40] it's new to me as well; looks like virt-install adding support for installing their cloud images by prepping some in-image cloud-init ; [16:58] Odd_Bloke: rharper Steve's suggestion to use debconf-loadtemplate adds a dependency on debconf-utils that cloud-init doesn't currently have. That adds about 57K of packages if we made this strict package dependency. Would we want to avoid adding this package unless someone specified ubuntu-drivers cloud-config? [16:58] blackboxsw: let's check in #ubuntu-devel with vorlon for alternatives/thoughts [16:59] sounds good [17:10] hello [17:10] how do i install a cloud-init server, not instance? for example, i have kvm server for vm deployment and want to use cloud init for cloud images VMs [17:12] besides of .iso images with cloud file metadata settings, is there network way to init vm ? [17:36] mator: hi, I'm not sure that I understand your questions; but it sounds like you'd be interested in Ubuntu cloud-images[1], which are Ubuntu server images with cloud-init already installed. And if you aren't running these images on a cloud, you'll want to learn to use cloud-init's NoCloud datasource[2], which allows cloud-init to find configuration on secondary devices (like a cdrom); 1. http://cloud-images.ubuntu.c [17:36] om/daily/server/bionic/current/ 2. https://cloudinit.readthedocs.io/en/latest/topics/datasources/nocloud.html [18:59] rharper: blackboxsw: https://write.wrestle.town/oddbloke/dracut-findings-for-cloud-init <-- your thoughts would be appreciated [19:58] Odd_Bloke: if we were to go down the route of extending dracut to emit a more friendly/standardized network configuration instead of cloud-init growing the ability to parse dracut's config, what is the possibility that we have issues upstreaming dracut fixes for cloud-init if needed? If we have issues with dracut upstream, I'm not certain what *we* would do to host our own official yum repo, other than our dev [19:58] copr repos [19:59] with the option of cloud-init proper growing dracut-parsing logic, we control the publishing of that feature, so if we have bugs, we can be certain that we fix them quickly and fast-track public releases of cloud-init that can cope [20:02] blackboxsw: We won't be able to push any dracut changes back into the releases that people actually care about, I don't think. [20:04] Getting dracut to emit v2 network YAML would be very nice, but we'd only be able to glean the benefits in several years, really. [20:04] So we need something to bridge that gap. [20:07] ohh /me misread "2. implement parsing in the dracut initramfs code" as implementing it in dracut package. [20:07] Ah, yes, that's confusing wording. [20:07] Let me fix that up. [20:08] blackboxsw: Is that clearer? [20:09] +1 Odd_Bloke [20:09] Thanks for the catch! [20:10] I'd agree with path 2. Odd_Bloke until we have more use cases [20:10] s/catch/getting confused myself/ [20:10] :) [22:49] Odd_Bloke: rharper for tomorrow: just put up ubuntu-drivers v2 https://code.launchpad.net/~chad.smith/cloud-init/+git/cloud-init/+merge/371546 [23:02] blackboxsw: cool