| otubo | smoser: quick ping on that PR: https://github.com/canonical/cloud-init/pull/721 | 10:25 |
|---|---|---|
| wCPO | Are cloud providers expected to override the "system_info -> distro" in metadata? It sounds weird, but I just got that response from a provider. | 15:01 |
| rharper | wCPO: no; distros may override the distro defaults in their downstream package, but upstream works with distros to try to have reasonable defaults; | 15:38 |
| smoser | otubo: ok. i'll push "update" there and then when c-i finishes i'll push merge. | 15:42 |
| wCPO | If I just want to disable vendor_data because they are borked, what is the best way to do that? I just tried providing a userdata with vendor_data: "", but that (as expected?) didn't work. | 15:44 |
| === hjensas is now known as hjensas|afk | ||
| rharper | wCPO: you want: vendor_data: {'enabled': false} | 15:49 |
| rharper | wCPO: your "" should also have worked, as long as the value is not a dict ... I would be interested in your cloud-init.log with your vendor_data value set ; you should see a message "vendordata consumption disabled" if it was successful | 15:52 |
| wCPO | rharper: could be a user error. I didn't expect it to setup the SSH key for both root and the default user | 15:56 |
| wCPO | enabled false does work | 15:56 |
| rharper | good | 15:56 |
| rharper | typically, root is disabled | 15:56 |
| rharper | cloudinit includes a warning when you ssh as root and point to the correct non-root user to login with | 15:57 |
| wCPO | They are also setting disable_root: false with a dropin in /etc/cloud/cloud.cfg.d/ and forcing the default user to root. So if you use a custom image you can't login :/ | 15:57 |
| rharper | some platforms, unfortuntely, want to provide a root login | 15:57 |
| rharper | bleh | 15:57 |
| rharper | in the vendor data? yeah, I've seen some crazy stuff in there (lookin at you DO ... ) | 15:57 |
| rharper | but user data lets you opt out of that | 15:58 |
| wCPO | Yeh, the DO vendor_data is annoying. Adding some magic automount logic | 16:01 |
| wCPO | rharper: the vendor_data: https://termbin.com/eb0z | 16:02 |
| rharper | that's a lot less messy that it used to be ... | 16:14 |
| rharper | several years back there were maybe 8 or 9 parts to the vendor_data ... | 16:14 |
| wCPO | That isn't from DO, but from Hetzner :) | 16:20 |
| otubo | smoser: thanks! | 16:53 |
| rharper | wCPO: ah! hehe | 16:56 |
| blackboxsw | smoser: otubo sorry for my absence on https://github.com/canonical/cloud-init/pull/721 did you resolve to drop the util.logexc in favor of info level messages? | 17:19 |
| blackboxsw | I'd also be leaning on the side of logging.info instead of big tracebacks as cloud-init has logs that are super noisy as it is, and we can capture the general sense of the problem/shortfall of cloud-init with a simple log in this case. But given that I didn't spend any time reviewing it other than the quick glance now, I'm ok with moving forward on that branch. | 17:20 |
| blackboxsw | and we can clean up logging and spurious logexc calls more broadly in cloud-init when we try to limit the about of logging in cloud-init in general to make those logs easier to parse for failures. | 17:21 |
| blackboxsw | I think we have another feature request in the wild related to trying to better classify log levels for subiquity too | 17:22 |
| blackboxsw | posted that samish comment on the PR. | 17:26 |
| === hjensas|afk is now known as hjensas | ||
Generated by irclog2html.py 2.7 by Marius Gedminas - find it at mg.pov.lt!