[15:11] <apollo13> hi there, is there a way to growpart & resizefs non-root partitions? growpart allows for partition configuration, resizefs seems to only want to resize the rootfs?
[15:12] <apollo13> https://github.com/canonical/cloud-init/blob/bda164459fdd408cc6f7d0232259fc157b33f581/cloudinit/config/cc_resizefs.py#L246 haha lovely todo
[15:19] <jchittum> non-root partitions of the "originating" image? So like you choose to boot with, say, a 50gb disk, and you're partitioning that disk as part of cloud-init? And not, say, attaching a separate cloud based volume?
[15:47] <Odd_Bloke> meena: Hah, I'd forgotten all about rs-identify.
[15:47] <meena> Odd_Bloke: to be fair, it's not great :P
[15:50] <falcojr> I started one too...seems to be a theme
[15:52] <meena> how much faster can we be than 0.4 seconds?
[15:59] <Odd_Bloke> IMO the justification for a rewrite would be maintainability, not an increase in performance.
[16:01] <Odd_Bloke> (Which, in the context of cloud-init's broad use as noted by minimal, and of there being no other Rust in cloud-init, RIIR probably does not meet the justification threshold.)
[16:04] <falcojr> perf would actually be a reason too given how generators block boot and get invoked multiple times during boot...but...also agree with Odd_Bloke's parenthetical
[16:07] <Odd_Bloke> I vaguely recall there being some benchmarking which found that the limiting factor was disk contention and so using a faster language wasn't faster.
[16:08] <Odd_Bloke> (And shell was used over Python because /bin/sh will already be memory-resident and Python won't be.)
[16:21] <holmanb> if you know where the results of the benchmarking would be found, I'd be curious about that @Odd_Bloke
[16:22] <holmanb> disk contention would be dependent on the platform (and possibly much less relevant depending on how long ago the benchmarking was - NVMe is much faster than spinning rust)
[16:28] <Odd_Bloke> I don't know where, I'm afraid: I was still working on the cloud images when it was happening, IIRC.  But that does mean it was done A While Ago, yeah.
[16:33] <Odd_Bloke> That said, ds-identify runs on boot of every Ubuntu server these days, I think?  So assuming fast storage that you might (reasonably!) expect in cloud environments may not be appropriate.
[16:38] <holmanb> my comment wasn't meant to assume fast storage by default
[16:38] <holmanb> rather that we might be leaving performance on the table where we do have it
[16:44] <Odd_Bloke> Yeah, that's definitely a possibility!
[19:31] <minimal> apollo13: ~I think the name of the config setting "resize_rootfs" kind of gives away the intended purpose ;-)
[19:34] <minimal> apollo13: for growing partitions other than the one containing rootfs you can specify "devices:" setting inside "growpart:" to provide a list of mountpoints whose partitions are to be grown
[19:35] <minimal> apollo13~: of course you can inside opt for calling "growpart" and "resize2fs" (or other fs-type equivalent) programs in a "runcmd:" section which is what I have done in the past
[19:38] <minimal> apollo13: one important point to note about the "growpart" scripts (used by cc_growpart), I assumes the partition to be grown is at the end of the disk (obviously with freespace after that partition) - i.e. you can't grow the 2nd of 3 partitions on the disk - definately if there's no free space between 2nd and 3rd and (from memory) even then growpart doesn't support that
[21:08] <fabiomirmar> @noahm, sorry to bug you with this again, but did you have any chance using ec2-net-utils with ubuntu or debian since the 2.4.1 release? I can't get it to work in either Ubuntu 22.04 (jammy) or Debian 12 (bookworm)
[21:09] <fabiomirmar> (last one that worked well for me was 2.4.0-1)
[21:32] <fabiomirmar> hmmm, in fact, that also happens to "yum update" in AL2023