| 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:25 |
|---|---|---|
| Nothing4You | seems like a limitation in current cc_resizefs | 00:50 |
| 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:58 |
| 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 :) | 00:59 |
| 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:01 |
| 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:02 |
| 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:03 |
| Nothing4You | https://bugs.launchpad.net/cloud-init/+bug/1955858 now i can go to bed :) | 01:10 |
| ubottu | Launchpad bug 1955858 in cloud-init "cc_resizefs does not allocate space on all disks of a multi disk btrfs volume" [Undecided, New] | 01:10 |
| 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:12 |
| 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:13 |
| 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:14 |
| 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:15 |
| Nothing4You | main reason i generate customized images is using btrfs for the root fs and using netplan | 01:16 |
| 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:18 |
| minimal | oh, not tried networkd - Alpine uses e/n/i like Debian and I've used both v1 and v2 network-config YAML | 01:19 |
| Nothing4You | an example of what my netplan config looks like https://gist.githubusercontent.com/Nothing4You/f19352da2fa8fe1be4d9a083971bb097/raw/0b5e32689726a2aaa08a74396946dc011aeb623c/gistfile1.txt | 01:20 |
| 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:21 |
| 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:22 |
| 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:23 |
| Nothing4You | https://bugs.launchpad.net/netplan/+bug/1846954 | 01:24 |
| ubottu | Launchpad bug 1846954 in netplan.io (Debian) "Route does not get removed when it's not defined anymore" [Undecided, New] | 01:24 |
| 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:25 |
| Nothing4You | https://bugs.launchpad.net/cloud-init/+bug/1909138 | 01:26 |
| ubottu | Launchpad bug 1909138 in cloud-init "cloud-init should officially support routes with source ip" [Wishlist, Fix Released] | 01:26 |
| 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:27 |
| Nothing4You | actually it was in january :D | 01:28 |
| 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:29 |
| minimal | thought there was some activity to add this for non-netplan - guess I was wrong | 01:30 |
| 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:36 |
| Nothing4You | next year != in another year :P | 01:37 |
| Nothing4You | actually you could interpret another as different rather than one more as well | 01:37 |
| Nothing4You | i guess both work | 01:38 |
Generated by irclog2html.py 2.7 by Marius Gedminas - find it at mg.pov.lt!