[00:28] <jnamdar> Hey everyone, is there anything planned to support adding DNF repositories from cloud-init config ? I saw in the doc there was a module to add YUM ones, but since RHEL 8 I think the default package manager is dnf.
[05:32] <holmanb> jnamdar: Just use the yum config module. It should work for dnf too.
[05:33] <holmanb> jnamdar: dnf still just uses repo files in /etc/yum.repos.d/, so unless they changed the format or something that module should continue to work
[05:42] <holmanb> I guess they left, but if anyone feels like verifying dnf support and updating docs to mention support, that would be a easy task for someone's first cloud-init contribution.
[05:43]  * holmanb looks forward to a future with github issues to categorize issues like this for new contributors
=== esv_ is now known as esv
[15:37] <emma14> hi, I'm trying to use cloud-init to configure my kvm-based VM. I'm mounting an ISO with a `user-data.txt` file in it, and it doesn't appear to be getting picked up when the VM boots after running `virt-sysprep` against the VM's disk - any suggestions?
[15:57] <minimal> emma: did you also create a meta-data file in the ISO? it is required
[15:58] <minimal> emma14: https://cloudinit.readthedocs.io/en/latest/reference/datasources/nocloud.html#file-formats
[15:58] <minimal> "Both files must be present for it to be considered a valid seed ISO."
[15:58] <emma14> Ah, right on, will give that a try
[16:24] <emma14> Doesn't seem to actually run anything I've specified. I'm generating a file `seed.iso` containing 3 files: `meta-data`, `user-data`, `network-config` which is a valid netplan schema. Mounting it through virt-manager as `SATA CDROM 1` with raw storage format. In-between each attempt I'm running `cloud-init clean --logs` to reset the
[16:24] <emma14> `/var/lib/cloud/`-directory
[16:25] <emma14> If I mount the ISO and run `$ cloud-init schema --config-file /mnt/cidata/user-data` it says it's valid as well
[16:26] <minimal> nothing related appeared in /var/log/cloud-init.log?
[16:32] <emma14> Hmm, I don't see anything particularly relevant. E.g. I don't see any mention of my user-data script or
[16:32] <emma14> This is just ubuntu20.04 server
[16:38] <emma14> Checking this ~ https://cloudinit.readthedocs.io/en/latest/reference/faq.html#where-are-the-logs ~ looks like /run/cloud-init/status.json indicates that the datasource is DataSourceNone
[16:38] <emma14> Do I need to manually specify the datasource somewhere?
[16:39] <minimal> there is a default list, that basically includes all the DataSources, with 'None' as the last one
[16:39] <emma14> I see
[16:39] <minimal> unless a specific DS or list of DS has been set somehow in /etc/cloud/cloud.cfg or in /etc/cloud/cloud.cfg.d/
[16:40] <minimal> look for a "datasource_list" entry
[16:41] <minimal> is the ISO labelled correctly?
[16:42] <zaphod_b> hiya lads; I'm trying to enable cloud-init on a regular ubuntu18 live-server image; my first attempts are failing, and I take it the presence of `/etc/cloud/cloud-init.disabled` is the culprit here
[16:42] <zaphod_b> so my question is, is there a way to override this with an option on the kernel command line for example ?
[16:43] <minimal> zaphod_b: why not use a Ubuntu cloud image?
[16:44] <zaphod_b> well this is for booting off metal; I had considered that at first, but could not find a way to get the hardware boot off any of the cloud images that I'd found
[16:44] <zaphod_b> but would love to learn otherwise :)
[16:44] <minimal> I *think* Live Server is using Subiquity
[16:45] <minimal> which then uses cloud-init
[16:45] <zaphod_b> well as far as I've understood, subiquity is a recent thing and probably was not yet around in 2018
[16:45] <zaphod_b> not quite sure about that
[16:45] <zaphod_b> how would subiquity be helpful ?
[16:46] <minimal> Ubuntu Server 18.04 uses Subiquity
[16:46] <emma14> > is the ISO labelled correctly? ~ from isoinfo - Volume id: cidata
[16:47] <minimal> well what I mean is that using Subquity (which uses cloud-init) is not exactly the same as using cloud-init "proper", 
[16:47] <zaphod_b> yes indeed; the scripts have written so far work fine with u20.04 and u22.04
[16:48] <minimal> emma14: the DS selection doesn't show much, if anything, in cloud-init.log unless you enable debug, then it shows exactly what is going on
[16:48] <emma14> Ah that's super helpful
[16:48] <emma14> I'll try that
[16:48] <minimal> emma14: then it will log the list of DSes it will check, you should see it looking for a fs labelled cidata, etc
[16:51] <minimal> zaphod_b: my point was that Live Server appears to use Subiquity for installing. So are you trying to install Ubuntu?
[16:51] <emma14> Following this ~ https://gist.github.com/RagedUnicorn/a70f8540c68e0a41e3e097a2e29130f1#logs
[16:52] <zaphod_b> not installing, running live
[16:52] <zaphod_b> and using cloud-init for setting ssh keys
[16:53] <minimal> zaphod_b: I don't think Live Server is designed for that
[16:55] <zaphod_b> well, clearly not, but with a little help the 20 and 22 versions have been willing to comply ;-)
[16:55] <zaphod_b> plus, that's called liver server, right ?
[16:55] <zaphod_b> plus, that's called live server, right ?
[17:05] <minimal> but does the cloud-init services run in sequence when you boot Live Server?
[17:05] <minimal> I'd expect not and that subiquity would run instead
[17:05] <zaphod_b> with u20 and u22, yes
[17:06] <minimal> hmm? you said you have a cloud-init.disabled file so then how can the c-i services run?
[17:08] <minimal> emma14: that guide does not mention increasing loglevel, only moving where the logfile is placed
[17:08] <zaphod_b> that file is present on the u18 image only
[17:10] <minimal> zaphod_b: right, seems things were changed in Ubunto 20: https://discourse.ubuntu.com/t/cloud-init-and-the-live-server-installer/14597
[17:17] <zaphod_b> minimal: thanks, this is helpful
[17:18] <blackboxsw> zaphod_b: minimal right. Just a  drive by comment from me. The live server installer is subiquity-based for the installation dialogs etc. I just launched the bionic live server iso the installer. Ubuntu 18 was a special case that does disable cloud-init intentionally within the ephemeral/installed environment. What I think this means is that you won't be able to provide any custom cmdline options to 'enable' cloud-init because most of 
[17:18] <blackboxsw> what I'd tell you would be something akin to ...
[17:20] <minimal> blackboxsw: yeah I wasn't sure what would happen if "cloud-init=enabled" was passed on cmdline
[17:20] <blackboxsw> manipulating the kernel params to send something like autoinstall ds=nocloud-net;s=http://SOME_IP:8000/'   where you host a user-data/meta-data file to remove said /etc/cloud/cloud-init.disabled file. But, chicken and egg problem here. cloud-init is disabled in this stage on bionic 18.04 so it doesn't receive those directies to override and remove the disable flag file
[17:20] <zaphod_b> yeah that's what I'm about to conclude too despite several attempts
[17:21] <blackboxsw> I recall that the live installer puts in layers of files in the ephemeral environment, I'll see if there is a kernel param switch that can be provided to disalllow disabling cloud-init (I think it unlikely but i'll poke around)
[17:22] <zaphod_b> blackboxsw: thank you that would be very helpful indeed
[17:24] <minimal> blackboxsw: isn't that the cmdline value I posted?
[17:24] <zaphod_b> I'm already messing with the grub options; I guess my next option along that pass would be to override the squashfs to remove the disabling file, but that's another step further and I was really hoping I would be able to avoid that...
[17:25] <minimal> zaphod_b: trying to install bare metal from a cloud/vm image would depend on whether that image happened to include drivers and firmware for your bare metal host's network, storage, etc devices
[17:26] <minimal> I'm not familiar with the Ubunut cloud images so not sure, but assume the NoCloud VM tailored images must have at least some physical devices drivers
[17:27] <zaphod_b> yes, and that's the reason why I'd discarded that idea at first as it does not souond quite right
[17:28] <emma14> Okay I think I may see why I wasn't getting the results I expected. When I ran `cloud-id` it said `none`, so I checked the contents of /etc/cloud/cloud.cfg.d/* and sure enough, it specified `none`. Led me to this answer - https://bugs.launchpad.net/subiquity/+bug/1958377/comments/11 - which led me to download a cloud image from -
[17:28] <emma14> https://cloud-images.ubuntu.com/ - and now I'm seeing debuggable output in `/var/log/cloud-init-*` and `cloud-id` is showing nocloud. Makes sense
[17:28] -ubottu:#cloud-init- Launchpad bug 1958377 in cloud-init (Ubuntu) "cloud-init does not apply network configuration from NoCloud resource" [High, Incomplete]
[17:40] <blackboxsw> minimal nice on `cloud-init=enabled` Yeah. zaphod_b minimal looks like providing the extended kernel params after --- cloud-init=enabled will enable cloud-init in BIonic's ephemeral boot stage I can see it camping out trying to discover a datasource in the KVM console 
[17:40] <blackboxsw> s/camping out/spinning/
[17:41] <blackboxsw> this is with stock 18.04.6 bionic live server ISO
[17:48] <NightMonkey> Howdy. I'm having a heck of a time getting cloud-init clean to have its expected effect on Ubuntu 22.04. What is the proper way to prep a "golden image" template.
[17:48] <NightMonkey> ?
[17:48] <zaphod_b> blackboxsw: indeed, this is awesome !
[17:49] <zaphod_b> thank you blackboxsw minimal for all the help !
[17:49] <meena> NightMonkey: which of your expectations aren't met?
[17:51] <NightMonkey> meena: I would like cloud-init to run on the next boot after the os image is cloned. 
[17:51] <jnamdar> Hi all, is there any doc to add dnf repositories ? I found the doc for yum repos, but those are outdated on Fedora/RHEL 8
[17:52] <meena> jnamdar: dnf uses rpm repositories, so the yum module should just work
[17:52] <NightMonkey> What I'm seeing, however, is that cloud-init doesnt even run.
[17:52] <meena> NightMonkey: anything in the logs as to why?
[17:52] <blackboxsw> NightMonkey `cloud-init status --long` may tell you what gives (also could check /run/cloud-init/ds-identify.log)
[17:52] <minimal> NightMonkey: which version of Ubuntu is this with? cloud image? Ubuntu server?
[17:53] <jnamdar> meena yeah but i'm afraid if the module writed in /etc/yum.repos.d/, the dnf command will probably not pick them up
[17:53] <jnamdar> writes*
[17:54] <blackboxsw> zaphod_b: just cofirmed I can run `python3 -m http.server 8000` with a directory containing `user-data` file with my #cloud-config and an empty meta-data  file and I can 'install ubuntu' on the live server 18.04 image passing the following kernel cmdline params:  `--- cloud-init=enabled ds=nocloud-net;s=http://_gateway:8000/' and it honors my #cloud-config
[17:54] <meena> try it out and tell us about it, if it doesn't work, we'll fix it
[17:55] <blackboxsw> zaphod_b: note as well that the #cloud-config user-data provided is manipulating the ephemeral boot stage, not the target system across reboot
[17:57] <zaphod_b> blackboxsw that's fine as I only intend to run in live mode, so not leaving the ephemeral boot stage
[17:59] <blackboxsw> zaphod_b:  For what it's worth we're working on getting a architecture diagram and examples together as this is a big pain point and confusion for lots of people (ephemeral interaction vs target system interaction) given that cloud-init is active in both boots
[18:05] <zaphod_b> indeed the whole business can be a headache ;-)
[18:08] <NightMonkey> meena: That's part of the problem. I see no logs from cloud-init.
[18:09] <meena> is it enabled? is logging enabled?
[18:09] <NightMonkey> In case it is a local misconfiguration, I'll ask this: does anyone here make golden images with Ubuntu 22.04 and see cloud-init run after running "cloud-init clean"? :)
[18:10] <NightMonkey> meena: I see it as a unit in systemd, but it is "inactive/dead".
[18:11] <NightMonkey> I also see a file in /etc/rsyslog.d/ that disables cloud-init logging, but I disabled that file. :/
[18:11] <blackboxsw> NightMonkey: yes, but what platform are you trying to launch that golden image in after creating it?    cloud-init status --long should tell you why cloud-init is disabled.
[18:12] <NightMonkey> @blackboxsw: Ah, I'll try that on Monday. Thank you.
[18:12] <blackboxsw> NightMonkey: +1 cloud-init status --long and read /run/cloud-init/ds-identify.log
[18:13] <blackboxsw>  ds-identify.log is the first entry point for cloud-init and decides whether the platform looks compatible with cloud-init
[18:13] <blackboxsw> ds-identify will deactivate all systemd units if it doesn't look like a viable datasource for cloud-init exists
[18:13] <blackboxsw> ok ... I really need to file my taxes. catch you all later. thanks!
[18:15] <NightMonkey> Oh, awesome, thanks a bunch!