[00:25] <Nothing4You> 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] <Nothing4You> seems like a limitation in current cc_resizefs
[00:58] <minimal> Nothing4You: probably. There's WIP currently for dealing with LVM using cc_growpart/cc_resizefs
[00:58] <Nothing4You> i'm writing a bug report right now
[00:58] <Nothing4You> the problem is it's using `btrfs filesystem resize max /` which only resizes the first volume
[00:58] <Nothing4You> *disk
[00:58] <Nothing4You> if you don't pass a disk id it uses disk id 1 by default
[00:59] <minimal> Nothing4You: you could always use "runcmd:" to do the correct commands yourself
[00:59] <Nothing4You> you'd need to get a list of all disk ids from btrfs and then run resize for each one
[00:59] <Nothing4You> yeah, i'll have to do that as workaround, until a patch hits debian years go by :)
[01:01] <minimal> 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] <Nothing4You> yeah, for now i'm just documenting, it's 2am already, i need to get some sleep
[01:02] <Nothing4You> 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] <Nothing4You> so i might just do that
[01:02] <Nothing4You> if it's not too complicated
[01:02] <minimal> 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] <minimal> 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] <Nothing4You> https://bugs.launchpad.net/cloud-init/+bug/1955858 now i can go to bed :)
[01:12] <minimal> 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] <Nothing4You> 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] <Nothing4You> nothing needed to be done in the image directly
[01:14] <Nothing4You> unfortunately in proxmox the way to pass user data is quite limited
[01:14] <Nothing4You> basically via gui/api you can only set very few variables
[01:15] <Nothing4You> for more configuration you need to manage snippets (files on the host filesystem) which there is no api for at this time
[01:15] <Nothing4You> and then attach those files via `qm set` to the vm
[01:15] <minimal> 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] <Nothing4You> main reason i generate customized images is using btrfs for the root fs and using netplan
[01:18] <minimal> netplan on Debian? hmm......
[01:18] <Nothing4You> netplan is specifically because i have network configuration that cannot be represented by the default renderer
[01:18] <Nothing4You> yeah
[01:18] <Nothing4You> netplan with networkd
[01:19] <minimal> oh, not tried networkd - Alpine uses e/n/i like Debian and I've used both v1 and v2 network-config YAML
[01:20] <Nothing4You> an example of what my netplan config looks like https://gist.githubusercontent.com/Nothing4You/f19352da2fa8fe1be4d9a083971bb097/raw/0b5e32689726a2aaa08a74396946dc011aeb623c/gistfile1.txt
[01:21] <minimal> 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] <Nothing4You> 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] <minimal> networkd is from systemd right? has Debian switched over to use it rather than e/n/i?
[01:23] <Nothing4You> as in from: in routes
[01:23] <Nothing4You> yes, systemd
[01:23] <Nothing4You> no, iirc debian still defaults to e/n/i
[01:23] <Nothing4You> playing with from: in routes is rarely used, even more rarely changing the from: value at runtime
[01:24] <Nothing4You> https://bugs.launchpad.net/netplan/+bug/1846954
[01:25] <Nothing4You> https://cloudinit.readthedocs.io/en/latest/topics/network-config-format-v2.html does not explicitly list "from:" as valid value for routes
[01:25] <Nothing4You> i had this issue before which resulted in the netplan passthrough paragraph being added at the top of the page
[01:26] <Nothing4You> https://bugs.launchpad.net/cloud-init/+bug/1909138
[01:27] <minimal> did we talk about this on here maybe 6 or so months ago? it sounds familiar
[01:27] <minimal> just had a quick look at network_state.py and yes it doesn't seem to handle the source aspect of routes
[01:28] <Nothing4You> actually it was in january :D
[01:29] <minimal> 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] <minimal> thought there was some activity to add this for non-netplan - guess I was wrong
[01:36] <Nothing4You> anyways 2:35am, actually gonna get some sleep now
[01:36] <Nothing4You> thanks for the talk, we'll probably continue in another year or so :)
[01:36] <minimal> that's less than a week away ;-)
[01:36] <minimal> see ya
[01:37] <Nothing4You> next year != in another year :P
[01:37] <Nothing4You> actually you could interpret another as different rather than one more as well
[01:38] <Nothing4You> i guess both work