/srv/irclogs.ubuntu.com/2024/01/30/#cloud-init.txt

* meena will be submitting her patches to incus first, due to licensing…00:00
holmanbmeena: https://github.com/canonical/cloud-init/pull/482000:07
-ubottu:#cloud-init- Pull 4820 in canonical/cloud-init "wip: Respect runtime file locations" [Open]00:07
meenaholmanb: thanks. I'll read through it now, and give it whirl tomorrow00:09
meenaholmanb: 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-b7f391573ff78195af6488fc62f2055dead52262126a0e153dfc29be752c5c5eR25900:13
-ubottu:#cloud-init- Pull 4820 in canonical/cloud-init "wip: Respect runtime file locations" [Open]00:13
holmanbmeena: oh I don't like it either00:14
holmanbmeena: but our rundir is defined in a config file00:14
holmanbto get our rundir, we need to read a config file00:15
holmanbthat's the chicken/egg I mentioned in the bug00:15
meenaI 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
holmanbyes - and currently cloud-init assumes both incorrectly00:15
meenaour AIX port puts it somewhere in /opt, IIRC…00:15
holmanbto determine at runtime which directories to use, we have to get this information from somewhere (conf file, env var, kernel cmdline, etc)00:17
holmanbthe PR doesn't change that - it just reduces the number of assumptions so that cloud-init can behave "better"00:18
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:19
holmanbI'm pretty sure the /etc assumption is hardcoded in ds-identify too00:21
minimalcouldn'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:23
minimalthat would give cloud-init a few bonus points in buzzword bingo00:24
holmanbHehe00:25
blackboxswcan't wait for the adoption of cloud-init to skyrocket once we have full ChatGPT integration. `cloud-init solve-my-config <rando_string>`00:25
meenaholmanb: right, which is why https://github.com/canonical/cloud-init/pull/448500:33
-ubottu:#cloud-init- Pull 4485 in canonical/cloud-init "ds-identify: FreeBSD fixes" [Merged]00:33
holmanbnice, that's right00:34
holmanbideally cloud-init python code would respect the same variable00:34
meenaholmanb: 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:09
holmanbmeena: I'd have to check, but i think it's not finding it and just falls back to the built-in config01:13
meenaI am pretty, and sure, that our config is effective01:14
holmanbthen I'll have to check01:15
meenahttps://codeberg.org/FreeBSD/freebsd-ports/src/commit/a45a9e175af5c54066a85c35582a7063a85f1557/net/cloud-init/files/patch-cloudinit_settings.py01:16
meenaWe patch it01:17
meenaand that patch will need updating soon lol01:17
meenaAlso, 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.cfg01:18
=== sam_ is now known as isosam
=== isosam is now known as sam_
meenaminimal: 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 \13:14
=== cpaelzer_ is now known as cpaelzer
minimalmeena: I'm not that familiar with libvirt, I prefer to use qemu-system-x86_64 directly15:33
meenaaye15:34
meenahttps://gitlab.com/qemu-project/qemu/-/issues/67816:29
-ubottu:#cloud-init- Issue 678 in qemu-project/qemu "eject (monitor command) not work for blockdev cdrom" [Opened]16:29
dbungertwould current cloud-init be expected to show warnings on apt sources being "configured multiple times"?20:22
blackboxswdbungert: current cloud-init in noble will emit a warning that it moved any duplicate /etc/apt/sources.list out of the way if it exists20:35
blackboxswWARNING:20:35
blackboxsw- Removing /etc/apt/sources.list to favor deb822 source format20:35
blackboxswand FTR, the source.list file still exists in noble until https://code.launchpad.net/~juliank/livecd-rootfs/+git/livecd-rootfs/+merge/458366 lands20:36
dbungertblackboxsw: thanks.  would you expect that behavior with cloud-init 24.1~4gd9677655-0ubuntu1 ?20:36
blackboxswyep 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
blackboxsweven 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:38
dbungertis that warning tied to a particular cloud_*_modules module?20:40
dbungertcc_apt_configure seemingly, I'll dig more20:41
blackboxswsorry 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:43
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:45
dbungertwell, 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:46
blackboxswdbungert: 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 definition20:52
blackboxswso if you didn't have apt_configure in /etc/cloud/cloud.cfg either that'd also prevent running the cc_apt_configure module20:52
blackboxswahh oops I missed the "were not present in cloud.cfg," and interpreted that as the python module not present on disk20:53
blackboxswand 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:55
dbungertright, 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:58
blackboxswsounds good20:59
meenacatred: https://github.com/catmsred/cloud-init/pull/123:52
-ubottu:#cloud-init- Pull 1 in catmsred/cloud-init "distro: add eject FreeBSD code path" [Open]23:52

Generated by irclog2html.py 2.7 by Marius Gedminas - find it at mg.pov.lt!