[00:25] i'm trying to figure out how to properly auto grow a multi disk btrfs array, i can get cloud-init to resize the related partitions by passing them to growpart but the btrfs volume is only grown once for the first grown device [00:50] seems like a limitation in current cc_resizefs [00:58] Nothing4You: probably. There's WIP currently for dealing with LVM using cc_growpart/cc_resizefs [00:58] i'm writing a bug report right now [00:58] the problem is it's using `btrfs filesystem resize max /` which only resizes the first volume [00:58] *disk [00:58] if you don't pass a disk id it uses disk id 1 by default [00:59] Nothing4You: you could always use "runcmd:" to do the correct commands yourself [00:59] you'd need to get a list of all disk ids from btrfs and then run resize for each one [00:59] yeah, i'll have to do that as workaround, until a patch hits debian years go by :) [01:01] Nothing4You: like most opensource projects its often a case of workout how to add the support yourself and submit a MR - that's what I do when I hit an issue :-) [01:01] yeah, for now i'm just documenting, it's 2am already, i need to get some sleep [01:02] since i'm generating the images myself i could also just patch the relevant python file in my image generation script once i have a patch though [01:02] so i might just do that [01:02] if it's not too complicated [01:02] I do something similar - I manage the Alpine Linux packaging so I often come up with a fix, patch it into the Alpine package, and also raise an MR to get it fixed upstream later [01:03] c-i is released quarterly, next release (22.1) is due late Feb from memory. Though of course Debian may take sometime after that to package it [01:10] https://bugs.launchpad.net/cloud-init/+bug/1955858 now i can go to bed :) [01:10] Launchpad bug 1955858 in cloud-init "cc_resizefs does not allocate space on all disks of a multi disk btrfs volume" [Undecided, New] [01:12] Nothing4You: haven't used ProxMox yet, was there anything special you had to do to whatever Linux distro you're using to get cloud-init working with ProxMox? [01:13] minimal: i'm building a customized version of the official debian-11-generic-amd64 cloud image, but that's mostly unrelated to cloud-init [01:14] nothing needed to be done in the image directly [01:14] unfortunately in proxmox the way to pass user data is quite limited [01:14] basically via gui/api you can only set very few variables [01:15] for more configuration you need to manage snippets (files on the host filesystem) which there is no api for at this time [01:15] and then attach those files via `qm set` to the vm [01:15] cool that's there's nothing need for VM - I have a script for creating cloud-init enabled Alpine disk images and have been intending to test it with ProxMox sometime [01:16] main reason i generate customized images is using btrfs for the root fs and using netplan [01:18] netplan on Debian? hmm...... [01:18] netplan is specifically because i have network configuration that cannot be represented by the default renderer [01:18] yeah [01:18] netplan with networkd [01:19] oh, not tried networkd - Alpine uses e/n/i like Debian and I've used both v1 and v2 network-config YAML [01:20] an example of what my netplan config looks like https://gist.githubusercontent.com/Nothing4You/f19352da2fa8fe1be4d9a083971bb097/raw/0b5e32689726a2aaa08a74396946dc011aeb623c/gistfile1.txt [01:21] nothing out of the ordinary in there - I've used that sort of config fine with e/n/i on Alpine, I'd assume it would also be fine for e/n/i in Debian [01:22] not sure if it was a c-i or e/n/i limitation but i think it was the source aspect that wasn't supported somewhere [01:22] networkd is from systemd right? has Debian switched over to use it rather than e/n/i? [01:23] as in from: in routes [01:23] yes, systemd [01:23] no, iirc debian still defaults to e/n/i [01:23] playing with from: in routes is rarely used, even more rarely changing the from: value at runtime [01:24] https://bugs.launchpad.net/netplan/+bug/1846954 [01:24] Launchpad bug 1846954 in netplan.io (Debian) "Route does not get removed when it's not defined anymore" [Undecided, New] [01:25] https://cloudinit.readthedocs.io/en/latest/topics/network-config-format-v2.html does not explicitly list "from:" as valid value for routes [01:25] i had this issue before which resulted in the netplan passthrough paragraph being added at the top of the page [01:26] https://bugs.launchpad.net/cloud-init/+bug/1909138 [01:26] Launchpad bug 1909138 in cloud-init "cloud-init should officially support routes with source ip" [Wishlist, Fix Released] [01:27] did we talk about this on here maybe 6 or so months ago? it sounds familiar [01:27] just had a quick look at network_state.py and yes it doesn't seem to handle the source aspect of routes [01:28] actually it was in january :D [01:29] yes it was me, the 2nd bug is familiar - it was me who told you that it working for netplan might be an unintended side-effect rather than by design (which oddbloke then clarified) [01:30] thought there was some activity to add this for non-netplan - guess I was wrong [01:36] anyways 2:35am, actually gonna get some sleep now [01:36] thanks for the talk, we'll probably continue in another year or so :) [01:36] that's less than a week away ;-) [01:36] see ya [01:37] next year != in another year :P [01:37] actually you could interpret another as different rather than one more as well [01:38] i guess both work