[04:54] <punkgeek> how can i import a shell script to the vm by cloud-init?
=== tds3 is now known as tds
[09:27] <andras-kovacs> Hi! Do you have any official images in Azure with cloud-init + LVM? The meta data collector part and runcmd don't work for me with my custom image.
[09:27] <andras-kovacs> It was almost the same with OpenStack + LVM, but cloud-init could collect the meta data there and runcmd didn't work at all.
[09:28] <andras-kovacs> I've tried to comment all the mount, resizefs and growpart related modules
[09:28] <andras-kovacs> but no luck :(
[09:28] <andras-kovacs> I really don't want to rely only on that stupid waagent
[09:28] <andras-kovacs> I like cloud-init
[12:05] <meena> 11:27 <andras-kovacs> Hi! Do you have any official images in Azure with cloud-init + LVM? The meta data collector part and runcmd don't work for me with my custom image. ⬅️ is there any other way to growfs in Linux than LVM?
[12:23] <andras-kovacs> meena: sorry is it a question? By default cloud-init will increase your root or other pre-defined partition early in the boot time. It never worked for me with LVM but I wrote a script for that. My problem now is other modules don't work also when I haven LVM on my disk.
[12:26] <andras-kovacs> Now I'm struggling with https://cloudinit.readthedocs.io/en/18.5/topics/datasources/azure.html
[12:26] <andras-kovacs> And now I had to remove cloud-init from my images with LVM because even if cloud-init services are disabled, waagent will start whining because of cloud-init's dhclient scripts.
[13:45] <Odd_Bloke> andras-kovacs: I'm not aware of any images using LVM, no.  What's the use case?
[13:47] <Odd_Bloke> meena: You don't need LVM to grow partitions on Linux, generally only for more complex use cases.
[14:15] <andras-kovacs> The use case is some legacy colleagues and strange apps -> not in the good way. LVM is a must... :(
[14:17] <andras-kovacs> I still want to enjoy/utilize cloud-init + make my VM templates auto-grow to the selected flavor, use the datasources, etc.
[14:17] <andras-kovacs> With OpenStack, the runcmd oart was ignored + I had to make a custom script to increase the LVM.
[14:17] <andras-kovacs> With Azure, not the the datasource/meta-data part, neither runcmd works with LVM. :(
[14:17] <andras-kovacs> I think I'll open an issue/bug report for you with all the details soon.
[14:18] <Odd_Bloke> Yep, sounds like a bug would be useful.
[14:18] <andras-kovacs> (I'll do the same for the dhclient vs NetworkManager lease files also just like you've recommended Odd_Bloke )
[14:19] <Odd_Bloke> FWIW, I would suggest not using the root disk of your instances for whatever complicated layout you want, but I understand that may not be practical. :)
[14:19] <andras-kovacs> And sorry for me whining all the time... cloud-init is just great and I really like it
[14:19] <Odd_Bloke> :)
[14:22] <andras-kovacs> this is how silly me made the root volume grow automatically: https://pastebin.com/FbggLAXJ
[14:22] <andras-kovacs> (xfs is also a must)
[17:26] <meena> "legacy colleagues" is a new one…
[17:33] <smoser> andras-kovacs: https://bugs.launchpad.net/cloud-init/+bug/1799953
[17:33] <ubot5> Ubuntu bug 1799953 in cloud-utils "growpart does not work for lvm" [Medium,Triaged]
[18:29] <Odd_Bloke> rharper: blackboxsw: https://github.com/canonical/cloud-init/pull/326 <-- this should fix Jenkins failures we've been seeing
[18:30] <rharper> Odd_Bloke: nice ... I'm wondering if we need to have a general mock of net.read_sys_path like we do for util.subp
[18:31]  * rharper just recently ported the util.subp replacement from cloud-init to curtin to catch those leaking execs; 
[18:41] <Odd_Bloke> Yeah, that's a good thought.