* meena will be submitting her patches to incus first, due to licensing… | 00:00 | |
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:07 | |
meena | holmanb: thanks. I'll read through it now, and give it whirl tomorrow | 00:09 |
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:13 | |
holmanb | meena: oh I don't like it either | 00:14 |
holmanb | meena: but our rundir is defined in a config file | 00:14 |
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:15 |
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:17 |
holmanb | the 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 |
holmanb | I'm pretty sure the /etc assumption is hardcoded in ds-identify too | 00:21 |
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:23 |
minimal | that would give cloud-init a few bonus points in buzzword bingo | 00:24 |
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:25 |
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:33 | |
holmanb | nice, that's right | 00:34 |
holmanb | ideally cloud-init python code would respect the same variable | 00:34 |
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:09 |
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:13 |
meena | I am pretty, and sure, that our config is effective | 01:14 |
holmanb | then I'll have to check | 01:15 |
meena | https://codeberg.org/FreeBSD/freebsd-ports/src/commit/a45a9e175af5c54066a85c35582a7063a85f1557/net/cloud-init/files/patch-cloudinit_settings.py | 01:16 |
meena | We patch it | 01:17 |
meena | and that patch will need updating soon lol | 01:17 |
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 | 01:18 |
=== sam_ is now known as isosam | ||
=== isosam is now known as sam_ | ||
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 \ | 13:14 |
=== cpaelzer_ is now known as cpaelzer | ||
minimal | meena: I'm not that familiar with libvirt, I prefer to use qemu-system-x86_64 directly | 15:33 |
meena | aye | 15:34 |
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] | 16:29 | |
dbungert | would current cloud-init be expected to show warnings on apt sources being "configured multiple times"? | 20:22 |
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:35 |
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:36 |
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:38 |
dbungert | is that warning tied to a particular cloud_*_modules module? | 20:40 |
dbungert | cc_apt_configure seemingly, I'll dig more | 20:41 |
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: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 |
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:46 |
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:52 |
blackboxsw | ahh oops I missed the "were not present in cloud.cfg," and interpreted that as the python module not present on disk | 20:53 |
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:55 |
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:58 |
blackboxsw | sounds good | 20:59 |
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] | 23:52 |
Generated by irclog2html.py 2.7 by Marius Gedminas - find it at mg.pov.lt!