/srv/irclogs.ubuntu.com/2025/01/24/#cloud-init.txt

holmanbdean: hello o/ can you please be more specific about the problem? 06:39
faiqushi folks im currently working on a cloud-init datasource for cluster-api-provider-aws. some background here when CAPA would provision a machine it would take the initial user-data, and then download more "secure" userdata from aws ssm. after downloading that it would restart cloud-init.16:37
faiqusthe code for this new datasource is here now https://github.com/kubernetes-sigs/image-builder/pull/158 and everything seems to be populated in the right place. the file /var/lib/cloud/instances/i-<instance-id>/cloud-config.txt has all the correct contents16:39
faiqusbut nothing actaully runs. would someone be able to help me figure out what's going wrong 16:39
deanDoes '/etc/cloud/cloud-init.disabled' exist?16:57
faiqusls: cannot access '/etc/cloud/cloud-init.disabled': No such file or directory17:02
faiqusthe data also isn't templated by jinja either 17:32
faiqusi feel like i need to do this with a boothook?17:32
faiqusfor example i see this 17:33
faiqus    name: '{{ ds.meta_data.local_hostname }}'17:33
connor_kI'm experimenting with including a shell script in vendor data, and it seems to work on fresh instances (gets written and executed) when I set the Content-Type to text/cloud-boothook or text/x-shellscript. But when I try text/x-shellscript-per-instance it gets written under /var/lib/cloud/scripts/vendor/per-instance/ but I do not see it executed in /var/log/cloud-init.log on a fresh instance like I do with the other content types. Does anyone have 17:46
connor_kany ideas for further debugging this?17:46
connor_k"scripts_vendor" is listed under cloud_final_modules. I noticed there's also "scripts_per_once", "scripts_per_boot", "scripts_per_instance". Are there vendordata analogs to those I need to factor in?17:47
minimalfaiqus: was ds-identify updated to know about/detect this new DataSource?18:08
holmanbfaiqus: the link you shared doesn't appear to be relevant to the issue that you described19:41
holmanbconnor_k: are you sure that it is really a fresh instance? if you run `cloud-init clean` and try rebooting does it work with the -per-instance script?19:43
connor_kholmanb: yeah, I've tried using cloud-init clean, but no avail. I also created brand-new VMs where using the x-shellscript-per-instance and didn't observe the "Running command ... " line in /var/log/cloudinit.log like I did with the other content types19:44
holmanbconnor_k: err, is looking for identical logs the only way that you're checking if it is worki9ng?19:45
minimalholmanb: in the gh pull he referenced there's a comment from "faiq" which has a link to the DS code in question19:47
minimalhttps://github.com/kubernetes-sigs/image-builder/compare/main...faiq:image-builder:custom-ami-ds19:48
holmanbweird, for me the link redirects to this issue which doesn't appear relevant: https://github.com/kubernetes-sigs/image-builder/issues/15819:51
-ubottu:#cloud-init- Issue 158 in kubernetes-sigs/image-builder "Ensure the SSM agent is installed and running in AWS images" [Closed]19:51
minimalyeah that happened to me also earlier19:52
minimalah, the original url was truncated, there's a missing "3"19:53
minimal#158319:53
holmanbgotcha, thanks19:53
minimalI don't understand why that DS is trying to restart the cloud-init service...19:54
connor_kholmanb: no, the script should `echo hello >> /tmp/helloworld.txt` -- I was mainly referencing the cloud-init logs since I thought it would be forensically useful when I noticed that the Running command ... appeared in the logs for each content-type that worked for me but was absent when I switched the content-type to text/x-shellscript-per-instance19:58
holmanbminimal: it's not trying to restart the cloud-init service20:05
holmanbit's commenting out the restart in the cloud-init service20:05
holmanbit's convoluted20:06
minimalah ok20:06
holmanbfaiqus: Pastbin the logs, please.20:09
holmanbconnor_k: you too20:12
faiqushi folks sorry i had to step out. i will paste bin the logs momentarily 20:23
faiqushttps://pastebin.com/Du9A8ds420:25
holmanbfaiqus: also /var/log/cloud-init.log 20:26
faiqusthat is entirely empty20:27
holmanbfaiqus: ahh right, if memoryy serves correctly you have a custom log configuration20:27
faiqus wc -l /var/log/cloud-init.log 0 /var/log/cloud-init.log20:27
faiqusso yeah this /var/lib/cloud/instances/i-<>/user-data.txt has all the bits but there are two issues with it. 1. the jinja templates aren't rendered 2. it doesn't run20:28
holmanbfaiqus: you'll need to figure out where those logs are going or switch to the default log configuration temporarily20:29
faiqushow would i do that? 20:30
holmanbfaiqus: under /etc/cloud/cloud.cfg.d there is a file20:30
holmanbprobably 05_logging.cfg20:30
holmanbthat should have the log configuration20:31
holmanbthis is the upstream default: https://github.com/canonical/cloud-init/blob/main/config/cloud.cfg.d/05_logging.cfg20:31
faiqusit looks almost identitical to the upstream one 20:32
faiqushttps://pastebin.com/NuBGupMM20:33
holmanbfaiqus: well it's not identical, the term which defines the log file is different20:34
faiqusoh sorry - the "almost" was doing a lot of work in the last message. what should i change?20:35
holmanbI don't know all the details of your setup20:36
holmanbbut I'd try just using the upstream default configuration20:37
faiqusok i will copy and paste that.20:37
faiqusim gonna build a new ami and run it - stay tuned. and thank you again for the help 20:38
faiqusholmanb: modifiying the log file to the upstream has given me a lot of logs. let me prepare a pastebin for you 21:10
faiqusholmanb: https://pastebin.com/a5HqKVsR21:12
faiqusthe cloud-init-output.log looks about the same as the previous paste 21:15
holmanbfaiqus: is the secret user-data always a jinja configuration?21:24
faiqusyeah, it will have jinja configuration. 21:25
faiqusi think almost always because it needs the host name 21:26
faiqusi couldn't find any convience functions to template that data in other datasources 21:33
faiqusyes, any time cloud-init will process the "secret" userdata there will be jinja configuraiton21:41
connor_kholmanb: I think I found a lead: https://github.com/canonical/cloud-init/commit/42f2cffadabfefb0469ade2f1f1c3ce5edabc9fa22:16
-ubottu:#cloud-init- Commit 42f2cff in canonical/cloud-init "remove vendor-scripts-per-{boot,instance,once}"22:16
faiqusim trying to parse the data but i can't seem to do that either. i imported this function -- render_jinja_payload_from_file. but its complaining that neither of these files: /run/cloud-init/instance-data-sensitive.json /run/cloud-init/instance-data.json is present22:41

Generated by irclog2html.py 2.7 by Marius Gedminas - find it at mg.pov.lt!