=== esv_ is now known as esv
[01:25] <holmanb> blackboxsw: stock gnome-terminal colors and neovim, but this is a peak at the neovim prompt https://imgur.com/VS2AkCW
[01:30] <holmanb> It needs some polish, but I have some userdata that will set up a pre-configured kinetic image and open neovim to write a schema :)
[01:30] <holmanb> in one easy one-liner ;)
[01:30] <holmanb> lxc stop neovim && lxc rm neovim && lxc init images:ubuntu/kinetic/cloud neovim -c user.user-data="$(curl https://gist.githubusercontent.com/holmanb/75e0974c759dd6180cdf74da6fd01551/raw/c70ffba3e454957754923eaf8060ef4b3feaaa27/user-data-schema-neovim.yml)" && lxc start neovim && lxc exec neovim -- sh -c "cd /root && cloud-init status --wait && nvim user-data.yml"
[02:03] <blackboxsw> holmanb: awesome! I got stuck on the LUA plugin setup there. one nit: use `-c cloud-init.user-data` as the new top-level config variable name for cloud-init stuff in lxd 5.0. The  user.(network-config|meta-data|vendor-data|user-data) are deprecated 
[02:03] <blackboxsw> also could use use `lxc launch` instead of `lxc init` so you can drop the `lxc start neovim`
[02:04] <blackboxsw> really nice gist there. lots of heavy lifting
[03:32] <holmanb> blackboxsw: Thanks for the suggestions! Will update tomorrow.  This reminds me I need to start keeping my configs in version control.
[12:26] <Guest37> Hi Team
[12:27] <Guest37> We use cloud init multi part via terraform for auotmated deployment of our application during instance spin up in aws cloud
[12:28] <Guest37> For this deployment, we created shell script in userdata and invoke ansible playbook in the same. But the ansible execution is slow
[12:29] <Guest37> Whereas when execute same shell script manually, the execution happens very fast
[12:29] <Guest37> Can someone share your suggestions
[12:33] <Guest37> Can someone clarify this
[13:45] <holmanb> Hi Guest37: Do you have an example? I have never tried what you're talking about, but I could take a look at it.
[14:55] <Guest57> I'm booting centos-stream-8 with cloud-init 21.1-11.el8. I'm using qemu with the -kernel option which skips the initramfs and uses my custom built kernel that I'm testing. cloud-init is failing with cloud-init[427]: 2022-05-13 14:49:34,038 - util.py[WARNING]: Failed to resize filesystem (cmd=('xfs_growfs', '/'))  .
[14:57] <Guest57> I did find this bug https://bugs.launchpad.net/cloud-init/+bug/1677376, which seems to indicate it should be fixed, so I'm not sure why there's still an issue
[14:57] <ubottu> Launchpad bug 1677376 in cloud-init (Ubuntu Yakkety) "growing partitions does not work when booted without initramfs" [Medium, Fix Released]
[15:08] <Guest57> I just tested wit centos-stream-9 and I get the same error
[15:12] <minimal> Guest57: that bug appears to be a Ubuntu-specific one. Is there anything else in cloud-init.log to indicate why the xfs_growfs failed for you?
[15:17] <Guest57> It does work if I set resize_rootfs: False. cloud-init.log says "Stderr: xfs_growfs: / is not a mounted XFS filesystem". With resize_rootfs: False I can log in and mount shows "/dev/vda1 on / type xfs (rw,relatime,seclabel,attr2,inode64,logbufs=8,logbsize=32k,noquota)".
[15:19] <Guest57> This is how I'm launching the image https://pastebin.com/SxfRVnQ9
[15:29] <minimal> Guest57: what version of cloud-init is Centos Stream 9 using?
[15:29] <blackboxsw> hrm,  `lxc launch images:centos/9-stream c9 lxc exec c9 yum install cloud-init gives me cloud-init version 22.1` which I can confirm has that related "fix" per that bug
[15:30] <blackboxsw> edit,  `lxc launch images:centos/9-Stream c9; lxc exec c9 yum install cloud-init;` Gives me cloud-init version 22.1, which I can confirm has that related "fix" per that bug
[15:31] <paride> minimal, I just tagged cloud-utils 0.33, I hope we're in time for Alpine :)
[15:31] <minimal> Guest57: also when you set "resize_rootfs: False" and booted and logged in did you try running "xfs_Growfs /" manually to see if that worked?
[15:32] <minimal> paride: thanks, should still be time, rc1 hasn't been made yet.
[15:32] <paride> minimal, great to hear
[15:55] <Guest57> Running xfs_growfs still fails with the same error and running xfs_info / shows "/: cannot find mount point" which is odd because it shows up in mount as an xfs mount of /dev/vda1.
[15:55] <holmanb> Guest57: you mentioned a custom kernel, and xfsprogs can have kernel-specific changes, tested by distro etc - have you tested your kernel to ensure that command passes manually after boot?
[15:55] <holmanb> Guest57: since cloud-init is just returning the output of xfsprogs (and you mentioned custom kernel, major red flag in this context) I'm inclined to say this isn't a cloud-init issue
[16:01] <holmanb> Guest57: Is this reproducible on the centos-stream-{8,9} default kernel?
[16:02] <Guest57> No, but with the default kernel its using grub and an initramfs. I'll try to put my custom kernel into the image and see if using the initramfs causes it to go away
[16:09] <minimal> Guest57: as xfs_growfs is failing when run manually then its no longer a cloud-init issue, its a more general OS issue
[16:10] <holmanb> agreed
[16:27] <blackboxsw> holmanb: I'm pulling the publish-schema PR back into WIP. I want to reorganize where the schema files all live under cloudnit.config.schemas so we can use relative links.
[16:28] <blackboxsw> relative schema $refs rather
[16:29] <holmanb> blackboxsw: sounds good, that's been on my mind too - the cloudinit/config/ with all the cc_ modules quite doesn't seem like the right fit anymore, especially since we're going to expand to network configs, metadata, etc
[16:39] <holmanb> try #2, that was barely decipherable:  "sounds good, that's been on my mind too. Storing the schemas in cloudinit/config/ with all the cc_ modules doesn't seem like the right fit anymore, especially since we're going to expand to network configs, metadata, etc"
=== jmcgnh_ is now known as jmcgnh