| Smithx10 | Does cloud-init 19 not work with the latest netplan stuff? | 01:41 |
|---|---|---|
| blackboxsw | Smithx10: it should. if a particular use-case isn't working, we'd love a bug. cloud-init should emit /etc/netplan/50-cloud-init.yaml on Ubuntu Bionic (18.04) or later | 04:33 |
| Smithx10 | I got it to work | 04:33 |
| Smithx10 | It took me a good 30 minutes to figure out what this thing was doing | 04:33 |
| Smithx10 | i still kinda have no idea what its doing | 04:33 |
| Smithx10 | but address ! | 04:34 |
| blackboxsw | yeah network-config for cloud-init could come from a variety of sources, kernel cmdline, datasource metadata or /etc/cloud/cloud.cfg.d files and cloud-init network renderers will spit out network configuration files (sysconfig, /etc/network/interfaces/ or /etc/netplan) based on what distribution it detects it is running on. | 04:37 |
| Smithx10 | yea, the logging is pretty errrr | 04:38 |
| Smithx10 | Also figured otu that I had to reboot the machine in order for it to configure an interface | 04:38 |
| blackboxsw | pretty noisy for sure | 04:38 |
| Smithx10 | Or I was running the wrong commands | 04:38 |
| Smithx10 | i was doing cloud-init clean and then unsetting the interface and downing it | 04:38 |
| Smithx10 | then running cloud-init init and it wouldnt do anything with it | 04:39 |
| Smithx10 | bouncing would configure it | 04:39 |
| blackboxsw | Smithx10: it depends on the datasource(cloud platform) you are running on what couldinit does. generally during reboot there are a number of stages where cloud-init wakes up and does some detection or configuration. All datasource and network config happens in either init-local stage (which is the command cloud-init init --local) or init-networking stage (which is the cloud-init init command you mentioned) | 04:42 |
| Smithx10 | Best place to see that is in the Modules code? | 04:42 |
| Smithx10 | What is donein local vs init? | 04:42 |
| blackboxsw | Smithx10: trying to run those individual commands is not really a supported flow for cloud-init because cloud-init does initial system configuration on boot (and actually runs the other configuration stages like modules and final which actually configure things like users and ssh keys etc. | 04:42 |
| blackboxsw | so missing any of the stages will likely lead to a misconfigured or partially configured system | 04:43 |
| Smithx10 | yea, I'm kind of blaming linux for this. | 04:43 |
| blackboxsw | heh :) https://cloudinit.readthedocs.io/en/latest/topics/boot.html | 04:43 |
| Smithx10 | The user is happy, their Distro is gettin an addr now | 04:43 |
| blackboxsw | Smithx10: to see what config modules are done in each stage: read /etc/cloud/cloud.cfg on your system | 04:44 |
| blackboxsw | the cloud_init_modules: list is what's run in init (network already up) stage | 04:44 |
| blackboxsw | cloud_config_modules: list == https://cloudinit.readthedocs.io/en/latest/topics/boot.html#config and cloud_config_final = https://cloudinit.readthedocs.io/en/latest/topics/boot.html#final | 04:46 |
| blackboxsw | in local: some datasources that can be detected before network being up get checked for discovery so they can emit the right network config before the system brings up it's full network stack. the rest of the details should be in https://cloudinit.readthedocs.io/en/latest/topics/boot.html#local | 04:47 |
| Smithx10 | hahaha | 04:55 |
| Smithx10 | and this is all better than running a bash script | 04:55 |
| Smithx10 | lol | 04:56 |
| Smithx10 | Not the point of cloud-init, i get it :P | 04:56 |
| Smithx10 | different problem | 04:56 |
| Smithx10 | Thanks for the advice | 04:56 |
| Smithx10 | I'll dive in tomorrow and with the docs in front of me find out more | 04:56 |
| blackboxsw | hehe :) | 04:56 |
| gfidente | hi guys, can anyone point me to the code distinguishing when a node is at is firstboot vs not-first? | 09:52 |
| gfidente | or maybe how is the instances id generated because I can clearly tell from the logs that it changed | 10:13 |
| === cpaelzer__ is now known as cpaelzer | ||
| MAbeeTT | hi, | 15:35 |
| MAbeeTT | I am trying to understand the cause of som errors logs in /var/lib/cloud-init.log I see this information https://pastebin.com/D4Fh4FmT | 15:36 |
| MAbeeTT | How could I understand how to get more info? Thanks in advance. | 15:37 |
| blackboxsw | MAbeeTT: looks like the hostname file that was written what not written as proper json.. strange. peeking one sec | 15:39 |
| blackboxsw | MAbeeTT: check /var/lib/cloud/data/set-hostname on your system to see if it looks like json | 15:41 |
| blackboxsw | you can cat it and paste here if you like | 15:41 |
| blackboxsw | or just ensure the following succeeds python3 -c 'import json; print(json.load(open("/var/lib/cloud/data/set-hostname")))' | 15:42 |
| MAbeeTT | ok, the idea is to understand how to proceed in next possible issues. | 15:45 |
| * MAbeeTT n00b. | 15:45 | |
| blackboxsw | one thing to also check is egrep 'Trace|Failed' /var/log/cloud-init.log as any issues setting the hostname in the first place (and writing that original set-hostname file) would have been emitted there | 15:45 |
| blackboxsw | so above that current failure I would have expected to see cloud writing to set-hostname too. so a grep set-hostname /var/log/cloud-init.log would show you the order of operations on hostname related activity | 15:47 |
| MAbeeTT | ok, file says `/var/lib/cloud/data/set-hostname: empty | 15:48 |
| MAbeeTT | ` | 15:49 |
| blackboxsw | strange as current cloud-init writes a dict always if it writes anything | 15:51 |
| blackboxsw | write_json(prev_fn, {'hostname': hostname, 'fqdn': fqdn}) | 15:51 |
| blackboxsw | cloud-init -v and cloud-id commands will tell us a bit more | 15:51 |
| blackboxsw | also sudo cloud-init query --all will show you all metadata that cloud-init is looking at on your system (careful there may be sensitive information in there if you setup passwords and keys in your userdata) | 15:52 |
| blackboxsw | and cloud-init query local_hostname should show you the standardized metadata value that cloud-init is sourcing when trying to set hostname | 15:53 |
| blackboxsw | for more info: https://cloudinit.readthedocs.io/en/latest/topics/instancedata.html | 15:54 |
| blackboxsw | ultimately this could be a bug once you track down where /var/lib/cloud/data/set-hostname is being written as empty. if so, run "ubuntu-bug cloud-init" and it'll allow you to create a bug and attach the cloud-init logs. | 15:55 |
| blackboxsw | if you are on Ubuntu that is. on other distros "cloud-init collect-logs" creates a tar of all artifacts/logs to aide in debugging) | 15:56 |
| * MAbeeTT reading | 15:57 | |
| MAbeeTT | this is a particualr instance ina lab, so there is no sensitie iformation, no problem. An error from my part is at the moment the best candidate for root cause. Anyway this is a good excuse for learning. | 16:00 |
| MAbeeTT | this is an ubuntu focal (20.04) vm in a proxmox PVE server, the cloud-init is generated by proxmox pve tool. (as cdrom drive). | 16:01 |
| blackboxsw | MAbeeTT: if you are providing user-data to the instance at boot, it generally is the most-likely source if deployment issues. try "sudo cloud-init query userdata > my-userdata.yaml; cloud-init devel schema --config-file my-userdata.yaml --annotate" it will at least validate your userdata is proper yaml and may give hints about failures | 16:06 |
| blackboxsw | run that on the system exhibiting failures just to double check a couple things about proper whitespace formatting. ... it's still work in progress (as we need better schema coverage) but it may find some glaring issues | 16:07 |
| blackboxsw | https://cloudinit.readthedocs.io/en/latest/topics/faq.html has some typical debug suggestions | 16:08 |
| MAbeeTT | great. | 16:09 |
| MAbeeTT | from the part of formatting it seems there are no problems `Valid cloud-config file /tmp/my-userdata.yml` | 16:12 |
| blackboxsw | ok, one ✔confirmed | 16:12 |
| MAbeeTT | `sudo egrep --color 'Trace|Failed' /var/log/cloud-init.log | wc -l 1` gives 3 tracebacks and 1 `Failed to get raw userdata in module rightscale_userdata`. Tis file is just last boot, previous boots are in cloud-init.log_ (just for clearance) | 16:18 |
| MAbeeTT | sudo cat /run/cloud-init/instance-data.json | jq '.v1.local_hostname' | 16:27 |
| MAbeeTT | shows the previous hostname (previous to cdrom rebuild and reboot) | 16:27 |
| MAbeeTT | well, i will be investiating diring the weekend, thanks you so much! | 16:28 |
| blackboxsw | rharper: is there anyway I can ammend the author of the latest commit without forcing people to rebase? Somehow my last squash and merge for AWS Fred's PR ended up giving 'me' authorship' | 18:08 |
| blackboxsw | maybe it's that the last commit on his branch he attributed to me via Test provided by: Chad Smith <chad.smith@canonical.com> | 18:09 |
| rharper | blackboxsw: hrm; ISTR we had something like this before | 18:09 |
| rharper | I thought it was supposed to have multiple authors or something like that | 18:09 |
| blackboxsw | I think we might have to add the directive Authored-by: <pr submitter> if it has multiple attributions | 18:12 |
| rharper | hrm | 18:13 |
| rharper | I'm out of my gitfu level here... | 18:13 |
| blackboxsw | strange is that that merge commit doesn't even have a merge marker from me vs the author like other merges I've squashed using the github ui | 18:15 |
| rharper | it wouldn't be terrible to amend with author fix; | 18:17 |
| blackboxsw | rharper: but that changes the commitish, so it might break consumers of tip | 18:18 |
| rharper | doing that sooner rather than later will reduce the number of rebases needed, no ? | 18:18 |
| rharper | only if they've pulled since that commit ? | 18:18 |
| blackboxsw | yes | 18:18 |
| rharper | I'm not saying do it Right Now, but I don't know another way; | 18:18 |
| rharper | maybe rbasak or other git folks know how best to handle this | 18:18 |
| blackboxsw | and if doing we changed the author, I'd also like to correct fomatting on the cmt message and add the LP:#1866290 | 18:19 |
| blackboxsw | worth a discussion in ubuntu-devel | 18:19 |
| rharper | yeah | 18:20 |
| blackboxsw | community-notice: Ubuntu focal upload of tip of cloud-init master accepted [ubuntu/focal-proposed] cloud-init 20.1-9-g1f860e5a-0ubuntu1 (Accepted) | 20:43 |
| blackboxsw | community-notice: Certified cloud images should update with 20.1-9 over the next couple of days | 20:43 |
| rharper | blackboxsw: nice! | 20:46 |
Generated by irclog2html.py 2.7 by Marius Gedminas - find it at mg.pov.lt!