| holmanb | amessyroom: Hrm, 19.4 sounds pretty old, lots of bugs fixed since then. I typically use https://paste.ubuntu.com/, or a github gist if I want to keep it for notes | 03:15 |
|---|---|---|
| amessyroom8 | reconnecting as amessyroom8 | 13:27 |
| blackboxsw | amessyroom sorry for the miss there. https://paste.ubunt.com or paste.opendev.org | 14:35 |
| amessyroom | seem to have some connection issues probably on my end; :-) anybody with experience using jinja templates in cloud-config files? I cannot seem to get them to work when cloud-init runs; but they work when I use cloud-init query --format="$(cat cloud-config-file.cfg)" | 15:26 |
| blackboxsw | amessyroom: you can paste to cloud-config-file.cfg to https://paste.ubunt.com or paste.opendev.org | 15:27 |
| blackboxsw | paste.ubuntu.com rather | 15:27 |
| === amessyroom47 is now known as amessyroom | ||
| blackboxsw | amessyroom: Here's a simple jinja example test on the commandline https://paste.opendev.org/show/bwmdCRg9ugV8nSS7bZdZ/ | 16:18 |
| amessyroom | thanks. I did that with my file; and it also shows evaulation but I cannot seem to get the same result when cloud-init is reran to test it . I try and go through the following steps to rerun: | 16:20 |
| amessyroom | #!/bin/bash | 16:20 |
| amessyroom | cloud-init clean --logs | 16:20 |
| amessyroom | cloud-init init | 16:20 |
| amessyroom | cloud-init modules --mode config | 16:20 |
| amessyroom | cloud-init modules --mode final | 16:20 |
| amessyroom | but no results. the actual string {{ name }} is displayed rather than it being updated. any suggestions on how I an troubleshoot it further. not finding anything in cloud-init.log nor cloud-init-output.log that have been helpful | 16:21 |
| blackboxsw | amessyroom: a reboot generally would do this (as you are missing a boot stage in your commands) you could either just run `cloud-init clean --logs --reboot` which will bring your system down (and then you can skip the other commands) or add `cloud-init init --local` above your `cloud-init init` command. https://stackoverflow.com/questions/23065673/how-to-re-run-cloud-init-without-reboot/71152408#71152408 | 16:24 |
| minimal | amessyroom: earlier you mentioned cloud-init 19.4 and holmanb indicated that is quite an ol version and possible to have related-bugs | 16:24 |
| blackboxsw | amessyroom: to debug what cloud-init officially saw as userdata `sudo cloud-init query userdata` | 16:24 |
| blackboxsw | thx minimal, missed the earlier conversation | 16:25 |
| amessyroom | i missed holmanb comment; i'm using what is provided from rhel7 repository. I was unhappy to see it was older. but wouldl prefer not to have to download/maintain another version. but if necessary I could. | 16:25 |
| amessyroom | let me try these other options and see if I get any output from the echo command | 16:26 |
| blackboxsw | also given that "{{ name }}" is being "seen" I'm guessing as well that cloud-init actually sees your user-data in the first place. I'd also `grep -i warning /var/log/cloud-init.log` too | 16:27 |
| blackboxsw | one last thought amessyroom: if the content you are providing as jinja templates is on disk in /etc/cloud/cloud.cfg.d note that cloud-init's jinja handlers don't actually render jinja templates from the filesystem as it is processed separately as raw cloud-config directives | 16:29 |
| amessyroom | only warning is about azure not finding a lease. does cloud-init "stop" executing scripts, if a failure occurs. on first-boot I create swap space and partitions; and when I rerun it seems to get failures trying to repeat it. for testing. I'm just adding a suffix to the .cfg file to skip it. don't know of a better wawy to no run it when it has | 16:30 |
| amessyroom | already been done. | 16:30 |
| blackboxsw | arguably, it would be a good feature for us to add though there are some timing concerns with when to source and render those config parts files as they are merged prior to datasource being detected I believe, which means that instance-data values are not avaiable yet for injection into jinja-templates | 16:30 |
| amessyroom | i'm going to try the reboot; i've seen it show that I'm on azure but not when I'm running manually so some things may not be available when running locally | 16:31 |
| amessyroom | i'm trying to configure everything in /etc/cloud/cloud.cfg.d in a image that is generalized and then used for vm creation. it seems there is a lot of user-data either via gui's or possibly being seed(ed) in /var/lib/cloud/seed directory -- so i've found learning where to put stuff confusing. | 16:33 |
| amessyroom | :-( still not change in output {{ v1.cloud_name }} {{ v1.instance_id }} {{ v1.local_hostname }} {{ v1.region }} | 16:34 |
| amessyroom | is there a specific module that has to be listed in /etc/cloud/cloud.cfg to enable the jinja templating ? I have removed some like "ec2" related stuff since I'm working on azure for current configuration. | 16:35 |
| amessyroom | https://pastebin.ubuntu.com/p/93gtnCv5Df/ | 16:36 |
| holmanb | amessyroom: iirc, rhel7 uses 19.4 because it was the last to support python2, which hasn't been maintained for a couple of years. I would personally be concerned about python2 critical security vulns if I was maintaining rhel7/cloud-init system. Food for thought wrt upgrading (assuming you already know this, but worth point out just in case). | 16:36 |
| amessyroom | thanks. i noticed the azure agent is python2 and brought up the same thoughts. | 16:37 |
| blackboxsw | amessyroom: I just read that you are putting jinja templates in /etc/cloud/cloud.cfg.d, as I said above too jinja templates are not read or rendered as jinja from /etc/cloud/cloud.cfg.d/*cfg. Those files are just system configuration data straight YAML that gets merged into common system configuration, not treated specifically as user-data which requires template handlers (like our jinja-handlers) to render that content. | 16:44 |
| amessyroom | i'm sorry I didn't get that the first time. I'll try and see if I can determine how to build some user data into the image; and generate my output file there. Thank you. | 16:45 |
| blackboxsw | so what happens is your #template: jinja headers are silently dropped from config and the strings {{ name }} are used verbatim | 16:45 |
| blackboxsw | no worries it is a bit confusing | 16:46 |
| blackboxsw | and it would be nice to handle declared templates in /etc/cloud/cloud.cfg.d/*cfg but not available yet :/ | 16:46 |
| blackboxsw | .. and it won't make it back to cloud-init 19.4 :) | 16:47 |
| amessyroom | seems like on azure the seed directory is pointing to /var/lib/waagent how should a user-data file be named; I've tried to create user-data but it doesn't seem to touch it on rerunning cloud-init. datasource: DataSourceAzure [seed=/var/lib/waagent] | 17:11 |
| blackboxsw | falcojr: I was just going through networkmanager support PR and trying to get my bearings on the failure condition there. So any newer distro who uses ntp will generally install chrony which delivers /usr/lib/NetworkManager/dispatcher.d/20-chrony*, the current ci.net.network_manager.active is incorrectly determining NM active just based on presence of that /usr/lib dir. So false positive in that case. | 17:12 |
| blackboxsw | falcojr: glad you are tightening down the "NM.active" assertions, though I'm playing around now with Ubuntu systems which have NM installed trying to get this activator/renderer to work effectively as I think there are some pieces missing from the original PR adding this renderer | 17:13 |
| blackboxsw | I think we may have a split-brain problem with activator priority not taking into account the configured renderer priority. If our renderer in ubuntu is chosen as netplan, yet nmcli is installed and active, cloud-init will choose the NetworkManager activator when it didn't write out any NM config due to emitting netplan instead. | 17:42 |
| blackboxsw | I think we may need to inform search_activators about the renders chosen by cloud-init earlier. | 17:43 |
| blackboxsw | because DEFAULT_PRIORITY of activators is [IfUpD, NetMgr, Netplan, Networkd] | 17:44 |
| minimal | blackboxsw: I assume any renderer specified in /etc/cloud/cloud.cfg will always be used first | 17:44 |
| blackboxsw | minimal: yes correct renderer specified in /etc/cloud/cloud.cfg will be selected based on that setting otherwise it will go to cloudinit.net.renderers.DEFAULT_PRIORITY [eni, sysconfig, netplan, network-manager, freebsd, netbsd, networkd] | 17:45 |
| blackboxsw | minimal: note that cloudinit.net.activators are not renderers though. They are the classes that actually interact with the network backend to bring up/down the configuration that the "renderers" write to disk | 17:46 |
| blackboxsw | so if cloud-init chose configured renderer "networkd" but the priority order of activators found ifupdown installed on the system. It looks to me like the IfUpDownActivator would get chosen to trying bringing up the interfaces. So if netplan configuration chose to render systemd-networkd config files, ifupdwon wouldn't know anything about the network config and would bring no devices up | 17:49 |
| blackboxsw | trying to piece that together to be sure. It just looks like a gap in which renderer vs which activator is chosen. And generally this will only show up on systems which have multiple network backends installed. | 17:49 |
| blackboxsw | trying to piece that together to be sure. It just looks like a gap in which renderer vs which activator is chosen. And generally this will only show up on systems which have multiple network backends installed and "active" | 17:49 |
| blackboxsw | 2 network backends is a recipe for problems in general. | 17:50 |
| blackboxsw | s/problems/complexity | 17:50 |
| blackboxsw | right, `Distro._write_network_state` determines the proper renderer and sources /etc/cloud/cloud.cfg , but activators are "detected" later when trying to bring up the written network configuration in `Distro.apply_network_config` Since the Distro doesn't preseve what renderer was chosen, it leads us down a path of rendering netplan, but trying to bring up specific activation with network manager. | 18:03 |
| blackboxsw | amessyroom: sorry user-data is specified to Azure not in the image itself, but via either providing in the dashboard during instance launch, or via azure's CLI `az vm create .... --custom-data your_jinja_template.yaml` if you are trying the rendering of that content | 18:06 |
Generated by irclog2html.py 2.7 by Marius Gedminas - find it at mg.pov.lt!