[09:28] 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] experience... [13:18] 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] 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] Dus10: cloud-init does not support Windows [13:24] however there is AFAIK a 3rd party cloudbase-init for Windows [13:24] cloud-init does support FreeBSD/OpenBSD/NetBSD/Dragonfly BSD as well as various Linux distros [13:26] structurally, cloud-init is so deeply embedded into Unix that i imagine it difficult to adapt for windows. [13:27] 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] *helped change it [13:28] meena: the cloudbase-init code is there if you want to see how it handle it: https://github.com/cloudbase/cloudbase-init [13:30] cool [13:31] I just had a coworker say he was using Cloud-Init instead of Packer lately and I was concerned about the efficacy [13:31] I would say it probably shouldn't be "instead of" but perfectly fine for "in conjunction with" [13:31] many of our customers have need for similar patterns with Windows and *nix systems... [13:32] learning a bunch of one off tools isn't great unless they provide overwhelming value [13:32] packer and cloud-init are different things really [13:32] packer would be for creating disk images [13:32] Yes, but Packer has a cloud-init provisioner [13:32] cloud-init is for performing configuration when such disk images are run [13:33] 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] one such tool being cloud-init [13:33] it basically "orchestrates" config tools and captures an image of the resulting system [13:34] Packer doesn't do the configuration [13:34] 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] yes, I also know what packer is [13:34] sounds like neither of us wants to be 'splained to [13:35] my original point is that packer and cloud-init are intended for different purposes [13:35] which is indeed why packer may well use cloud-init in some circumstances [13:37] and as you initially said you were "only tangentially aware of CloudInit" I was trying to point out that distinction [13:40] all good [13:40] I have run into similar things internally, so nothing to do with you [13:40] thank you for responding to my question [13:41] if I want to become more familiar with it, are the tutorials in the documentation sound ways to get familiar? [13:41] the documentation is very extensive [13:42] 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] I've had a bad week with documentation :) I am more skeptical than normal about it [13:43] using NoCloud as a datasource (where you create a small ISO with the required cloud-init YAML files) [13:43] I spent 4 hours this week making requests to fix massive gaps in documentation for several things [13:44] So, NoCloud kind of behaves like unattended files of the past? [13:45] 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] 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] 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] effendy[m]: if it's always the same, put it in the template [22:19] What is the same? Using ansible vs cloud-init, for instance? [22:21] if something needs configuration, at run time, put it in cloud-init, otherwise, put it in the image template