[00:00]  * meena will be submitting her patches to incus first, due to licensing…
[00:07] <holmanb> meena: https://github.com/canonical/cloud-init/pull/4820
[00:07] -ubottu:#cloud-init- Pull 4820 in canonical/cloud-init "wip: Respect runtime file locations" [Open]
[00:09] <meena> holmanb: thanks. I'll read through it now, and give it whirl tomorrow
[00:13] <meena> holmanb: I'm not happy with this, but maybe I just don't understand what it means: https://github.com/canonical/cloud-init/pull/4820/files#diff-b7f391573ff78195af6488fc62f2055dead52262126a0e153dfc29be752c5c5eR259
[00:13] -ubottu:#cloud-init- Pull 4820 in canonical/cloud-init "wip: Respect runtime file locations" [Open]
[00:14] <holmanb> meena: oh I don't like it either
[00:14] <holmanb> meena: but our rundir is defined in a config file
[00:15] <holmanb> to get our rundir, we need to read a config file
[00:15] <holmanb> that's the chicken/egg I mentioned in the bug
[00:15] <meena> I guess we'll have to test a few paths down the road, but assuming config is in /etc/ is like assuming /run is ephemeral 
[00:15] <holmanb> yes - and currently cloud-init assumes both incorrectly
[00:15] <meena> our AIX port puts it somewhere in /opt, IIRC…
[00:17] <holmanb> to determine at runtime which directories to use, we have to get this information from somewhere (conf file, env var, kernel cmdline, etc)
[00:18] <holmanb> the PR doesn't change that - it just reduces the number of assumptions so that cloud-init can behave "better"
[00:19] <holmanb> (and i yell about our assumptions in the comments so that people are forced to think about our assumptions when they read that code)
[00:19] <meena> *nod*
[00:21] <holmanb> I'm pretty sure the /etc assumption is hardcoded in ds-identify too
[00:23] <minimal> couldn't you just implement an AI module and get it to ask ChatGPT? AI (oh and don't forget Blockchain) is after all the current solution to all problems ;-)
[00:24] <minimal> that would give cloud-init a few bonus points in buzzword bingo
[00:25] <holmanb> Hehe
[00:25] <blackboxsw> can't wait for the adoption of cloud-init to skyrocket once we have full ChatGPT integration. `cloud-init solve-my-config <rando_string>`
[00:33] <meena> holmanb: right, which is why https://github.com/canonical/cloud-init/pull/4485
[00:33] -ubottu:#cloud-init- Pull 4485 in canonical/cloud-init "ds-identify: FreeBSD fixes" [Merged]
[00:34] <holmanb> nice, that's right
[00:34] <holmanb> ideally cloud-init python code would respect the same variable
[01:09] <meena> holmanb: how are we doing it right now? how does cloud-init on FreeBSD know to look under /usr/local/etc/cloud/ for its config? 
[01:13] <holmanb> meena: I'd have to check, but i think it's not finding it and just falls back to the built-in config
[01:14] <meena> I am pretty, and sure, that our config is effective
[01:15] <holmanb> then I'll have to check
[01:16] <meena> https://codeberg.org/FreeBSD/freebsd-ports/src/commit/a45a9e175af5c54066a85c35582a7063a85f1557/net/cloud-init/files/patch-cloudinit_settings.py
[01:17] <meena> We patch it
[01:17] <meena> and that patch will need updating soon lol
[01:18] <meena> Also, this one can be dripped now, https://codeberg.org/FreeBSD/freebsd-ports/src/commit/a45a9e175af5c54066a85c35582a7063a85f1557/net/cloud-init/files/patch-config_cloud.cfg.d_99__freebsd.cfg
[13:14] <meena> minimal: I got a new version of qemu now, and eject doesn't work for me. This, btw, is how I do it: 
[13:14] <meena> -blockdev '{"node-name":"libvirt-1-format","read-only":true,"driver":"raw","file":"libvirt-1-storage"}' \
[13:14] <meena> -device scsi-cd,bus=scsi0.0,channel=0,scsi-id=0,lun=0,device_id=drive-scsi0-0-0-0,drive=libvirt-1-format,id=scsi0-0-0-0 \
[15:33] <minimal> meena: I'm not that familiar with libvirt, I prefer to use qemu-system-x86_64 directly
[15:34] <meena> aye
[16:29] <meena> https://gitlab.com/qemu-project/qemu/-/issues/678
[16:29] -ubottu:#cloud-init- Issue 678 in qemu-project/qemu "eject (monitor command) not work for blockdev cdrom" [Opened]
[20:22] <dbungert> would current cloud-init be expected to show warnings on apt sources being "configured multiple times"?
[20:35] <blackboxsw> dbungert: current cloud-init in noble will emit a warning that it moved any duplicate /etc/apt/sources.list out of the way if it exists
[20:35] <blackboxsw> WARNING:
[20:35] <blackboxsw> 	- Removing /etc/apt/sources.list to favor deb822 source format
[20:36] <blackboxsw> and FTR, the source.list file still exists in noble until https://code.launchpad.net/~juliank/livecd-rootfs/+git/livecd-rootfs/+merge/458366 lands
[20:36] <dbungert> blackboxsw: thanks.  would you expect that behavior with cloud-init 24.1~4gd9677655-0ubuntu1 ?
[20:38] <blackboxsw> yep daily builds will still have that warning (and it'll be retained as cloud-init default behavior in noble ++) in latest daily cloudimage builds. Once the above MR to livecd-rootfs lands, then I'd expect daily builds of noble to no longer have that warning in cloud-init status output 
[20:38] <blackboxsw> even if we publish cloud-init tip to noble we'll still carry that warning because we want to alert image makers (ourselves) to potential misconfiguration.
[20:40] <dbungert> is that warning tied to a particular cloud_*_modules module?
[20:41] <dbungert> cc_apt_configure seemingly, I'll dig more
[20:43] <blackboxsw> sorry interrupt here yes it is a hard-coded warning level message https://github.com/canonical/cloud-init/blob/main/cloudinit/config/cc_apt_configure.py#L683  are you looking to squelch/silence that warning?
[20:45] <blackboxsw> ... there isn't a way to do that at the moment. But I'm just wondering if there is a 'demand' for the ability to filter/silence certain warning messages in cloud-init (network schema validation may be another area where consumers may not want cloud-init to be noisy in certain scopes of warnings)
[20:46] <dbungert> well, if cc_apt_configure were not present in cloud.cfg, then the warning would not come up.  Basically, I constructed ubuntu live-server to try to produce this warning and it didn't happen.  Now I can add cc_apt_configure to this ISO, as it is not configured today, and I expect to see the warning.
[20:52] <blackboxsw> dbungert: correct, when  cc_apt_configure  is one of those modules that are loaded and run always when present in images because the MetaSchema defines an empty `"activate_by_schema_keys": [],` which means include and attempt to run the module's handle if apt_configure is present  in /etc/cloud/cloud.cfg::cloud_config_modules YAML definition
[20:52] <blackboxsw> so if you didn't have apt_configure in /etc/cloud/cloud.cfg either that'd also prevent running the cc_apt_configure module
[20:53] <blackboxsw> ahh oops I missed the "were not present in cloud.cfg," and interpreted that as the python module not present on disk
[20:55] <blackboxsw> and I now grok you message fully, current installer images that you were playing with didn't have `- apt_configure` in the cloud_config_modules: list  in /etc/cloud/cloud.cfg and you weren't getting the warning which was potentially 'desired' in this case.
[20:58] <dbungert> right, with the config change on cloud.cfg I have exit status 2 and content in `cloud-init status --format=json` .modules-config.recoverable_errors.WARNING.  I think I'm set.
[20:59] <blackboxsw> sounds good
[23:52] <meena> catred: https://github.com/catmsred/cloud-init/pull/1
[23:52] -ubottu:#cloud-init- Pull 1 in catmsred/cloud-init "distro: add eject FreeBSD code path" [Open]