[00:04] <minimal> SuperLag: obviously using the "apt:" section is only going to work for apt/deb-based distros like Debian/Ubuntu, likewise using "yum_repos:" is only going to work for RPM-based distros
[13:49] <meena> anyone know what the best strategy is for getting https://github.com/canonical/cloud-init/pull/2157 tested? it looks like there's no unit tests for routes in the renderer tests right now, at all
[13:49] -ubottu:#cloud-init- Pull 2157 in canonical/cloud-init "Added / fixed support for static routes on OpenBSD and FreeBSD" [Open]
[14:49] <meena> very naïve patch: https://github.com/canonical/cloud-init/pull/2168 needs testing (but I've already got a VM with MBR setup)
[14:49] -ubottu:#cloud-init- Pull 2168 in canonical/cloud-init "FreeBSD (and friends): better identify MBR slices" [Open]
[15:28] <holmanb> minimal: thanks for helping threepistons, I see they've left now but I was going to mention that I learned about url/cloud-config-data recently when updating cloud-init docs.
[15:28] <holmanb> minimal: I was also initially under the impression that it was MAAS-only, however I think it's actually a feature that was requested for maas but made more general.
[15:31] <holmanb> It has a handful of shortcomings, which I tried to document better with the changes I made.
[15:31] <holmanb>  The interface feels very much like a bolt-on idea.
[15:31] <holmanb> So does the include file format for that matter.
[15:51] <minimal> holmanb: certainly for nocloud-net the include stuff, if it worked, would seem a bit clunky
[15:52] <holmanb> minimal: agreed
[15:53] <holmanb> but the fact that it does leaves is with a crappy ux - a documented format that works in some cases but not others
[16:08] <meena> https://github.com/canonical/cloud-init/issues/4 this should probably be closed now
[16:08] -ubottu:#cloud-init- Issue 4 in canonical/cloud-init "Agree with LaunchPad issue, either update of this repo or kill it" [Open]
[16:08] <falcojr> meena: heh, thanks. Just saw it too and was about to close it
[16:10] <meena> https://github.com/canonical/cloud-init/issues/3 and i don't even know what this is
[16:10] -ubottu:#cloud-init- Issue 3 in canonical/cloud-init "Linux VM fail to read admin_pass to reset the root password" [Open]
[16:10] <falcojr> it's just a very old issue that happened to "disappear" when we closed github issues many years back. We'll triage it accordingly in time
[16:33] <minimal> it seems to refer to a cloudbase-init (Windows cloud-init "clone") specific user-data setting: "admin_pass:"
[17:29] <meena> does Linux have an equivalent to https://github.com/freebsd/freebsd-src/blob/main/libexec/rc/rc.d/growfs ?
[17:30] <meena> I'm thinking of replacing the FreeBSD
[17:30] <meena> cc_growfs Code with `service growfs onestart`
[17:32] <minimal> cc_growfs? you mean cc_growpart or cc_resizefs? ;-)
[17:33] <minimal> for cc_growpart Linux typically uses growpart from cloud-utils
[17:33] <minimal> for cc_resize the program used depends on the particular filesystem, e.g. resize2fs for EXT2/3/4
[17:33] <falcojr> As announced the other week, I'm starting the bug migration from Launchpad to Github Issues today. If you have repo email notifications turned on for either Github or Launchpad, you might want to turn them off..
[17:39] <minimal> falcojr: where's that configured in Launchpad? I don't see it
[17:39] <falcojr> https://bugs.launchpad.net/cloud-init/+subscriptions
[17:41] <minimal> thankds
[17:51] <minimal> meena: there is no "standard" daemon for Linux to grow/resize partitions & fs. Also the c-i modules only manipulate the rootfs partition & fs, that FreeBSD daemon also deals with swap partition which c-i handles via cc_disk_setup
[18:08] <meena> I could literally just replace all three of those with a call to service growfs onestart
[18:09] <meena> aaaaand, i think it would probably be quite sensible
[18:10] <minimal> it depends ;-)
[18:10] <minimal> from memory with some cloud providers swap may go elsewhere
[18:10] <minimal> also someone may want a swapfile rather than a swap partition
[18:11] <minimal> and someone may want to control any partition or fs resizing (I added "overprovisioning" support to cloud-utils' growpart some time ago for SSD use)
[18:23] <meena> okay, so, more like, cc_growpart and cc_resizefs then
[18:24] <minimal> meena: my point about overprovisioning, for SSDs I typically want the partition resizing to ensure that a percentage (i.e. 10%) of the device is not partitioned (and so not used) to "help" the lifetime of the SSD
[18:25] <minimal> enterprise SSDs already tend to be overprovisioned, the above helps for consumer SSDs
[18:26] <minimal> I just haven't gotten around to adding the overprovisioning support to cc_growpart yet (the underlying tool has it for some time)
[18:29] <minimal> cc_growpart and cc_resize also need to handle "stacked" filesystems - i.e. fs-on-LVM, or fs-on-LUKS encryption, or fs-on-Software RAID, or fs-on-LVM-on-LUKS-on-Software Raid ;-)
[18:31] <minimal> so with fs-on-LVM you may want cc_growpart to grow the root partition to fill the disk and grow the LVM PV to fill the partition but *not* want cc_resizefs to grow the root LV or the rootfs inside the LV
[22:44] <meena> okay, I've added the pull request, I think I should mark it WIP, cuz I just realized this service only works for the root dev.
[22:44] <meena> (also, I really need to figure out how to make it not do the swap thing, cuz maybe some people like having servers without swap)
[22:45] <meena> it means they also have servers that can't crashdump, but, hey, who am I to judge?
[22:45] <meena> (I am very judgy when it comes to debugging crashed software)
[23:00] <minimal> does this block until the resizing is finished?
[23:12] <meena> yes
[23:13] <minimal> ok