[09:28] <effendy[m]> I eventually did something else, as stopping and starting the vmtoolsd would led to a restart before cloud-init finished. I've profited from the fact that vmware-tools uses old references, and so I've unlinked /usr/sbin/telinit altogether. I've no idea what the consequences are as of now, but only now did it work. As a temporary solution until I find something better. At least I can move forward and focus on the important stuff. Horrible
[09:28] <effendy[m]> experience...
[13:18] <Dus10> Hello!  I am only tangentially aware of CloudInit.  Does it only work for Linux-based workloads?  Can it work for other *nix stuff?  What about Windows?
[13:19] <Dus10> From what I am gathering... it seems like the use case is for Linux... just wanted to verify... a lack of words around Windows doesn't necessarily prove lack of support for it :)
[13:23] <minimal> Dus10: cloud-init does not support Windows
[13:24] <minimal> however there is AFAIK a 3rd party cloudbase-init for Windows
[13:24] <minimal> cloud-init does support FreeBSD/OpenBSD/NetBSD/Dragonfly BSD as well as various Linux distros
[13:26] <meena> structurally, cloud-init is so deeply embedded into Unix that i imagine it difficult to adapt for windows.
[13:27] <meena> but then again, a year ago, it was structurally deeply embedded into Linux and I've changed it enough to make room for BSD
[13:27] <meena> *helped change it
[13:28] <minimal> meena: the cloudbase-init code is there if you want to see how it handle it: https://github.com/cloudbase/cloudbase-init
[13:30] <Dus10> cool
[13:31] <Dus10> I just had a coworker say he was using Cloud-Init instead of Packer lately and I was concerned about the efficacy
[13:31] <Dus10> I would say it probably shouldn't be "instead of" but perfectly fine for "in conjunction with"
[13:31] <Dus10> many of our customers have need for similar patterns with Windows and *nix systems...
[13:32] <Dus10> learning a bunch of one off tools isn't great unless they provide overwhelming value
[13:32] <minimal> packer and cloud-init are different things really
[13:32] <minimal> packer would be for creating disk images
[13:32] <Dus10> Yes, but Packer has a cloud-init provisioner
[13:32] <minimal> cloud-init is for performing configuration when such disk images are run
[13:33] <Dus10> so, Packer makes a temporary system and makes sure the host running Packer can reach it, then it hands off configuration duties to different tools via the provisioners
[13:33] <Dus10>  one such tool being cloud-init
[13:33] <Dus10> it basically "orchestrates" config tools and captures an image of the resulting system
[13:34] <Dus10> Packer doesn't do the configuration
[13:34] <minimal> I know what packer, I've used it before. However my point is that packer is not designed/intended to be used on a deployed system, it is intended to create a disk image for such a deployed system
[13:34] <Dus10> yes, I also know what packer is
[13:34] <Dus10> sounds like neither of us wants to be 'splained to
[13:35] <minimal> my original point is that packer and cloud-init are intended for different purposes
[13:35] <minimal> which is indeed why packer may well use cloud-init in some circumstances
[13:37] <minimal> and as you initially said you were "only tangentially aware of CloudInit" I was trying to point out that distinction
[13:40] <Dus10> all good
[13:40] <Dus10> I have run into similar things internally, so nothing to do with you
[13:40] <Dus10> thank you for responding to my question
[13:41] <Dus10> if I want to become more familiar with it, are the tutorials in the documentation sound ways to get familiar?
[13:41] <minimal> the documentation is very extensive
[13:42] <minimal> however probably the best way to become familiar is to spin up a VM which has cloud-init present, like one of the various Linux distros' cloud images, and play with it
[13:42] <Dus10> I've had a bad week with documentation :)  I am more skeptical than normal about it
[13:43] <minimal> using NoCloud as a datasource (where you create a small ISO with the required cloud-init YAML files)
[13:43] <Dus10> I spent 4 hours this week making requests to fix massive gaps in documentation for several things
[13:44] <Dus10> So, NoCloud kind of behaves like unattended files of the past?
[13:45] <minimal> NoCloud looks for an ISO or other filesystem with a label of "cidata" which contains files like meta-data.yaml, user-data.yaml, network-config.yaml and uses those for cloud-init processing
[13:46] <minimal> most of the other DataSources are for various cloud providers where the talk to the provider's metadata server (via HTTP) to obtain the configuration info
[22:05] <effendy[m]> Dus10: I use packer with cloud-init, yes. Initially, I need it do to basically stuff, such as injecting ssh keys so that packer can connect afterwards to provision everything with ansible. Of course, I could have configured more in cloud-init directly through packer, but it seems easier/more robust to use ansible to create the templates.
[22:18] <meena> effendy[m]: if it's always the same, put it in the template
[22:19] <effendy[m]> What is the same? Using ansible vs cloud-init, for instance?
[22:21] <meena> if something needs configuration, at run time, put it in cloud-init, otherwise, put it in the image template