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 | 00:52 |
---|---|---|
holman | minimal hmm that's tricky | 01:12 |
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:14 |
minimal | otherwise that testcase fails because "which" for dmsetup fails | 01:15 |
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:17 |
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:19 |
holman | The existing code | 01:20 |
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:21 |
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:23 |
holman | Gotcha, nice | 01:31 |
holman | I just looked at the resizer classes as an example and they are quite weird | 01:46 |
holman | Wouldn't emulate them | 01:46 |
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:57 |
minimal | whereas currently the tests only deal with status/resize/luksKillSlot | 01:58 |
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/ | 01:59 |
holman | Oof | 07:59 |
=== esv_ is now known as esv | ||
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 :) | 12:50 |
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:46 |
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:51 |
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. | 14:53 |
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:20 |
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:21 |
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:23 |
Dr-Shadow | Ok I did grep the sources and I could see that it is not possible to do something like this | 15:33 |
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:34 |
minimal | related: #4920 | 15:42 |
Dr-Shadow | Yes I saw that issue as well | 15:53 |
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 | 15:59 |
Generated by irclog2html.py 2.7 by Marius Gedminas - find it at mg.pov.lt!