=== mamercad4 is now known as mamercad
[08:31] <cpaelzer> Hiho, just stumbled over this when checking for a bug
[08:31] <cpaelzer> on the docs at https://cloudinit.readthedocs.io/en/latest/topics/modules.html?highlight=ssh_authorized_keys#authorized-keys
[08:31] <cpaelzer> it reads "connect to a a user account on a system"
[08:32] <cpaelzer> a a <<
[08:32] <cpaelzer> seems wrong and a trivial fixup if you think it is worth
[08:32] <cpaelzer> falcojr: ^^ FYI
[08:44] <cpaelzer> also nowadays (impish and later) the dmesg call in https://cloudinit.readthedocs.io/en/latest/topics/bugs.html needs a sudo
[08:47] <cpaelzer> reported https://bugs.launchpad.net/cloud-init/+bug/1940236 and https://bugs.launchpad.net/cloud-init/+bug/1940235
[08:47] <ubottu> Launchpad bug 1940236 in cloud-init "requesting Minor doc fixes" [Undecided, New]
[08:47] <ubottu> Launchpad bug 1940235 in cloud-init "cloud-init collect-logs fails in impish" [Undecided, New]
[08:47] <cpaelzer> while I actually wanted to report https://bugs.launchpad.net/cloud-init/+bug/1940233
[08:47] <ubottu> Launchpad bug 1940233 in cloud-init "cloud-init   in impish makes /home/ubuntu/.ssh root.root" [Undecided, New]
[08:47] <cpaelzer> hattrick :-/
[11:52] <andyf> Hi all. I've been adding support for the illumos (née OpenSolaris) family of OSs to cloud-init.
[11:53] <andyf> Is this something you'd be interesting in my committing back?
[11:53] <andyf> It's generally been a pleasant experience, and there are abstractions in place for most things to make it easy
[11:54] <andyf> but I do have a couple of places where I don't know the right approach to take
[11:54] <andyf> and I've had to de-linuxify some of the modules - those would probably be best as separate commits
[12:37] <akutz> andyf: There is a place in netinfo.py where the logic splits between Linux and FreeBSD, so having additional logic for OpenSolaris seems to be in line with what is already happening elsewhere. Then again, it's been quite a while since I SPARCd up a conversation about Solaris :) Perhaps the differences are too large? Not sure.
[12:39] <andyf> Yes, having the *bsd support in there definitely made this job easier since there is already work there to remove some assumptions about the system. Adding illumos will further improve that I think.
[12:39] <andyf> We're definitely going to ship this in our OmniOS distribution, it's just a question of whether it can go upstream (which would be my preference!)
[12:40] <andyf> Some people in the illumos community are writing a cloud-init clone in Rust - so coming at it from the other angle
[12:40] <andyf> I would prefer to use the real thing since it's the industry standard
[13:34] <falcojr> cpaelzer: Thanks! Those are both really helpful
[13:34] <falcojr> andyf: yes, we would welcome those submissions upstream...just not the rust fork :P
[13:45] <andyf> falcojr: great! I'll start with a couple of small PRs to generalise a couple of the modules that make assumptions at the moment
[13:45] <andyf> they're small and it will give me a feel for the process etc.
[13:48] <cpaelzer> glad to hear that falcojr
[13:48]  * cpaelzer does not want to be the late-cycle killjoy
[13:48] <falcojr> cpaelzer: waaaaaaaaay better than post-release killjoy
[14:18] <rharper> andyf: totally interested in the rust fork;  primarily in 1) size and speed improvements 2) scope of features  included 3) how are the various modules cc_XX being handled (ported or kept in python) 
[14:21] <andyf> rharper: they are just doing something that works purely for illumos - a metadata client in rust that can use various datasources.
[14:21] <andyf> https://github.com/illumos/metadata-agent/
[14:23] <andyf> I think extending cloud-init is a better approach
[14:23] <rharper> nice, thanks for the link
[14:29] <minimal> rharper: there are various cloud-init "clones" around but they tend to have limited functionality and limited DS support
[14:29] <minimal> I've seen shell, C, and Golang "clones"
[14:29] <rharper> right; it's always a subset 
[14:30] <minimal> exactly, that's why I sorted out the cloud-init package for Alpine, the breadth of DS support is important
[14:30] <rharper> I'm generally interested in improving the core but I'd like to retain (without porting) all of the module support;  
[14:30] <andyf> Opened my first PR anyway :) I just need to sign the agreement (my browser is slow and keeps saying I got the captcha wrong, I'll try later from home)
[14:30] <rharper> yeah and Datasource support as well; 
[14:32] <minimal> as Alpine is a "minimal" Linux distro that's why I'm keen to reduce cloud-init's dependancies were possible.
[14:32] <akutz> Wait, is there an actual Rust fork of cloud-init? Interesting.
[14:32] <akutz> You have to have muscl memory when using Alpine :)
[14:33] <minimal> akutz: I'm all for keeping it minimal :-)
[14:34] <akutz> I also wonder if there's been any chatter in splitting cloud-init somewhat where the early bootstages have minimal deps and use as portable a language as possible, but by the time any user or vendor data is processed, a more featureful framework/language is present. 
[14:35] <akutz> Really I just want to use something more powerful than shell scripting for ds-identify :)
[14:36] <akutz> (and I am the person who wrote a 5,176 line, POSIX-compliant shell script for bootstrapping Kubernetes :) https://github.com/vmware-archive/simple-k8s-test-env/blob/master/sk8.sh
[14:37] <minimal> akutz: I'm keen to ensure that any shell scripts in cloud-init only rely on /bin/sh - I don't have bash on any of my Alpine boxes. Also that where possible that Busybox lightweight versions of common tools can be used (I'm currently working on a cloud-init PR to support Busybox's blkid so I can remove the dependancy on the "full" version of blkid)
[14:38] <falcojr> akutz: At one point Odd_Bloke was toying with a ds_identify clone in rust, but I don't think he got very far
[14:39] <akutz> minimal: Rely only on /bin/sh or be POSIX compliant? Because, as I've learned, there are differences. The use of "local" all over the place, for example. That's not technically allowed by POSIX-compliance standards, but I was told all shells support it, so....
[14:39] <minimal> akutz: relevant point, I'm the person who has written a 6,000+ line (and growing) shell script for creating cloud-init enabled Alpine VM/Cloud/physical machine disk images :-) https://github.com/dermotbradley/create-alpine-disk-image
[14:40] <akutz> I bring 5,176 and minimal comes back with 6,000+ :) 
[14:40] <akutz> Also, nice!
[14:41] <andyf> ksh93 does not support 'local' unless specifically compiled with support for it as a bash-compat thing
[14:42] <minimal> akutz: yeah POSIX-related is a bit of a gray area. Alpine's using ash by default which is a dash-equivalent shell. Agree with the support for "local", have noticed the same. I tend to run all my shell stuff through "shellcheck".
[14:42] <akutz> I've done a little work with Gardenlinux (https://github.com/gardenlinux/gardenlinux) and other projects that build VM disk images from scratch using a mounted FS in a container. It's always really cool, but I wish there was a way to make it more portable. 
[14:43] <akutz> I use shellcheck as well, and that is when I was told that shellcheck is too aggressive and local is okay. Still, I prefer to stick with standards, even when I disagree, for the sake of consistency.
[14:44] <minimal> akutz: look at my script, its using chroot with a static-compiled version of the Alpine "apk" package manager, plus binfmt/user-mode QEMU for creating images for a different arch. Its somewhat portable as the script should run on most Linux distros
[14:45] <akutz> Yeah, that's why I made the comment. I realized right away what you were doing :)