| 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... | 09:28 |
| 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:18 |
| 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:19 |
| minimal | Dus10: cloud-init does not support Windows | 13:23 |
| 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:24 |
| meena | structurally, cloud-init is so deeply embedded into Unix that i imagine it difficult to adapt for windows. | 13:26 |
| 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:27 |
| minimal | meena: the cloudbase-init code is there if you want to see how it handle it: https://github.com/cloudbase/cloudbase-init | 13:28 |
| Dus10 | cool | 13:30 |
| 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:31 |
| 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:32 |
| 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:33 |
| 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:34 |
| 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:35 |
| minimal | and as you initially said you were "only tangentially aware of CloudInit" I was trying to point out that distinction | 13:37 |
| 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:40 |
| 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:41 |
| 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:42 |
| 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:43 |
| Dus10 | So, NoCloud kind of behaves like unattended files of the past? | 13:44 |
| 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:45 |
| 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 | 13:46 |
| 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:05 |
| meena | effendy[m]: if it's always the same, put it in the template | 22:18 |
| effendy[m] | What is the same? Using ansible vs cloud-init, for instance? | 22:19 |
| meena | if something needs configuration, at run time, put it in cloud-init, otherwise, put it in the image template | 22:21 |
Generated by irclog2html.py 2.7 by Marius Gedminas - find it at mg.pov.lt!