[14:37] <beantaxi> jbg: Thank you for the answer the other day. May I ask you to clarify what you mean by 'set the cloud config from terraform'? I'm looking to work terraform into the mix but I'm trying to figur eout how
[14:39] <minimal> beantaxi: you're creating the VM from terraform? then you can specify user-data at that time for cloud-init to use
[14:40] <beantaxi> minimal: I'm not using terraform at all ... I'm doing all the resource creation (in Azure) through bash. But I'd get more buy-in if I used terraform so I'm curious as to how it would fit in. So terraform has a user-data section for VM creation? That sounds promising
[14:41] <blackboxsw> minimal: if you hadn't seen already 22.3.1 with the network_state MAC address fixes was released Friday https://discourse.ubuntu.com/t/release-of-22-3-1/30385 . Releases are downloadable at https://github.com/canonical/cloud-init/releases
[14:41] <beantaxi> jbg also mentioned a yamlencode() function ... I assume that implies I would need to write my cloud config as yaml (right now it's bash), but then I'd be all set?
=== blackboxsw changed the topic of #cloud-init to: 22.3.1 Released! | Bugs: https://bugs.launchpad.net/cloud-init/+filebug | PRs: https://git.io/JeVed | release schedule: https://discourse.ubuntu.com/t/cloud-init-2022-release-schedule/25413
[14:42] <minimal> blackboxsw: yeah I've got it locally packaged for Alpine already, just dealing with an unrelated Alpine issue before I raise an MR for the updated package ;-)
[14:46] <minimal> beantaxi: from a very quick look it seems that when using the azurerm_linux_virtual_machine resource you specific the user-data in the "custom_data" value
[14:46] <minimal> beantaxi: currently how are you provisioning on the cli? using az?
[14:47] <minimal> beantaxi: as an example, look at https://www.phillipsj.net/posts/cloud-init-with-terraform/  and search for "custom_data = "
[14:49] <beantaxi> minimal: Yes, lots of az calls. I've been a bit hesitant to start using terraform, because I was concerned I'd hit some limitation of the terraform azure stuff and I'd need to use az anyway
[14:53] <minimal> beantaxi: so "az vm create" has a "--custom-data" option which I assume is the equivalent method for passing user-daa
[14:55] <minimal> beantaxi: indeed this is examplained here: https://docs.microsoft.com/en-us/azure/virtual-machines/linux/using-cloud-init
[14:57] <beantaxi> Yes, that's correct. az vm create allows for a file, which is nice, whereas I don't see in a terraform data-block where I can refer to a file; it looks like I have to inline data. But I could easily be missing something.
[15:00] <beantaxi> I'm successfully using --custom-data with az now. And I can see where I could roll some sort of variable substitution, with sed or something, and convert $REPO_NAME$ to my_great_repo etc before passing a cloud-config file to the az call. But I wanted to see if there was already a very well-accepted way of doing that before I started DIYing it
[15:01] <beantaxi> Thanks very much for the links btw, esp the terraform link. Now I feel like I know how I'd get started, if I want to bring in terraform
[15:08] <beantaxi> Alternately, I could put my `cloud-init devel` hat back on, and look at adding something, if folks have suggestions on a preferred tool or templating technology, eg jinja
[15:12] <minimal> beantaxi: you mean templating of what is pass as user-data? rather than templated user-data being passed in (which I believe cloud-init can handle via Jinja)
[15:41] <beantaxi> minimal: From what I've read -- but admittedly might not understand -- there is jinja template support but only for instance data. I couldn't figure out if I could customize instance data with my own values, but even if I could, I'm not sure I'd want to do that
[15:43] <beantaxi> As it seems like an indirect way of doing what I want, which is just to replace a few variables in a config at VM creation time. Among other things I'd prefer to have a copy of the actual cloud config -- the one actually used for instance creation -- as an artifact
[15:51] <minimal> beantaxi: so if you decide to use terraform then use its templating? if you stick with shell then use one of the various methods of templating (jinja cli, gomplate, etc)
[16:00] <beantaxi> minimal: That's what it's sounding like. The terraform approach sounds like a bit of a non-starter, since it appears it only supports 
[16:01] <beantaxi> inlined data in cloud-config yaml format
[16:06] <beantaxi> So if I wanted something more flexible, it looks like I'd be better off starting with the cloud-init CLI, to produce the cloud config I want. Hopefully terraform will not make me copy/paste the result into a yaml -- I don't know much about terraform data sources etc but hopefully there's a way to refer to a file
[16:16] <minimal> beantaxi: why do you need the cloud-init cli to create cloud config (user-data?)? I create mine in a text editor, its just YAML
[17:55] <beantaxi> minimal: Currently I do the same ... I'm thinking of enhancing the cloud-init cli to do something like (cloud-config.sh.jinja, .env) => cloud-config.sh, where jinja is used to generate the output file from a template, which I believe could either be .yaml or .sh and would work fine either way
[17:57] <beantaxi> And .env could be optional -- in its absence it'd use envvars, assuming it's easy enough to invoke jinja with envvars as parameters 
[18:22] <minimal> beantaxi: how would that work? you'd have to install cloud-init on a machine just to use the cli to generate user-data files for other machines?
[20:46] <beantaxi> minimal: That is a concern. Some time ago, I recall some talk about cloud-init devel being broken out on its own, for cases such as these, ie help with cloud config creation. If that never happened, perhaps installing cloud-init to do all this isn't that appealing, vs the alternative
=== esv_ is now known as esv