[00:52] <minimal> help needed with modifying a testcase, I want to change this: https://github.com/canonical/cloud-init/blob/main/tests/unittests/config/test_cc_growpart.py#L484-L487 to handle 2 different programs being queried via "which" and so to give 2 different return_values back
[01:12] <holman> minimal hmm that's tricky 
[01:14] <minimal> yeah I added a "which" for dmsetup in cc_growpart.py and the test_encrypted_but_cryptsetup_not_found testcase needs to return "None" for "cryptsetup" (as it does currently) but return a path for "dmsetup"
[01:14] <minimal> https://github.com/canonical/cloud-init/blob/main/tests/unittests/config/test_cc_growpart.py#L538-L541
[01:15] <minimal> otherwise that testcase fails because "which" for dmsetup fails
[01:17] <holman> In the past I've used side_effect to return a list of ordered return values 
[01:17] <minimal> as in "real life" dmsetup binary might not be installed so that's why I added a which check for it
[01:19] <holman> The code logic sounds reasonable 
[01:19] <minimal> yeah I could try adding a side_effect similar to the _subp_side_effect one
[01:19] <holman> This test just doesn't sound very flexible
[01:20] <holman> The existing code
[01:21] <minimal> lol, so I'm finding as I've made other changes to cc_growpart as well - this is for handling LUKSv1 and also LUKSv2 (without keyfile) resizing
[01:23] <minimal> I've basically copied this whole existing "class TestEncrypted" into 3 sets: TestLUKv1Encrypted, TestLUKSv2dmkeyfileEncrypted, TestLUKSv2kernelkeyEncrypted
[01:23] <minimal> with similar, but not identical, testcases
[01:31] <holman> Gotcha, nice
[01:46] <holman> I just looked at the resizer classes as an example and they are quite weird
[01:46] <holman> Wouldn't emulate them 
[01:57] <minimal> I've add more, differing, cryptsetup subp calls as well as I've had to extend the _subp_side_effect to cater for "cryptsetup status", "cryptsetup isLuks", "cryptsetup resize", "cryptsetup luksKillSlot" differently
[01:58] <minimal> whereas currently the tests only deal with status/resize/luksKillSlot
[01:59] <minimal> basically it took me approx 1 week to make the cc_growpart changes I wanted and it's taken me off-and-on 2-3 months to try and test both existing testcases and new testcases working :-(
[01:59] <minimal> s/test both/get both/
[07:59] <holman> Oof
[12:50] <AhmedBM> Ive been attempting to write my own cloud-init module using the docs but having trouble getting my module to run.For context, in developing IN_PLACE using an lxd container for integration tests ive added to exercise the module. Upon inspection of the logs though i notice my module is never loaded when looking at the
[12:50] <AhmedBM> cloud-init/combined-cloud-config.json i notice my module isn't even under the "cloud_final_modules" which ive added to the cloud.cfg.tmpl. Any ideas as to what im doing wrong? Am i missing a build step even though im doing this in-place? Thanks in advance :)
[14:46] <Odd_Bloke> falcojr: Thanks!  I did see that, I was going to ask the maintainer to apply that patch (until I realised I was barking up the wrong tree entirely :) ).
[14:51] <Odd_Bloke> It turns our config drive provides `/etc/resolv.conf` content via `files`.  `/etc/resolv.conf` is a symlink to stub-resolv.conf, meaning that (a) stub-resolv.conf gets overwritten, and (b) systemd-resolved doesn't read its content (because it's already symlinked to a file it owns) and so comes up with no DNS servers configured.  Fedora configure /etc/nsswitch.conf so that `nss-resolve` is used
[14:51] <Odd_Bloke> to query systemd-resolved directly (and only falls back to resolv.conf if resolved is _down_), so `/etc/resolv.conf` _looks_ correct but resolution doesn't work.
[14:53] <Odd_Bloke> And to cap off the confusion, we have vendor-data to handle this case (albeit in a suboptimal way), but that only kicks in if `/etc/systemd/resolved.conf` is in the filesystem which it is in F39 but is not in F40.
[15:20] <Dr-Shadow> Hello, would anyone have an idea on how to tell disk_setup / fs_setup to add an UUID in the fstab instead of the path ?
[15:21] <Dr-Shadow> My fstab entry generated by cloud-init is like this : `/dev/disk/by-id/scsi-0QEMU_QEMU_HARDDISK_drive-scsi1-part1      none    swap    sw,comment=cloudconfig 0 0`
[15:23] <Dr-Shadow> I have cloud-init 22.4.2 since I'm on Debian 12 and I can't tell if using 24.1 would help
[15:33] <Dr-Shadow> Ok I did grep the sources and I could see that it is not possible to do something like this
[15:34] <Dr-Shadow> And `2024-04-24 15:13:10,751 - cc_mounts.py[DEBUG]: Changes to fstab: ['+ /dev/disk/by-id/scsi-0QEMU_QEMU_HARDDISK_drive-scsi1-part1 none swap sw,comment=cloudconfig 0 0']` pointed to cc_mounts.py
[15:42] <minimal> related: #4920
[15:53] <Dr-Shadow> Yes I saw that issue as well
[15:59] <Dr-Shadow> I'm not sure that's related because I think #4920 is about a problem when we provide a path to cc_mounts.py through user_data
[15:59] <Dr-Shadow> I'm not using `mounts:` config
[15:59] <Dr-Shadow> I opened a proper issue asking for enhancement
[15:59] <Dr-Shadow> I hope I'm not mistaken to do that