[10:25] <otubo> smoser: quick ping on that PR: https://github.com/canonical/cloud-init/pull/721
[15:01] <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:38] <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:42] <smoser> otubo: ok. i'll push "update" there and then when c-i finishes i'll push merge.
[15:44] <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.
=== hjensas is now known as hjensas|afk
[15:49] <rharper> wCPO: you want: vendor_data: {'enabled': false}
[15:52] <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:56] <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:57] <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:58] <rharper> but user data lets you opt out of that
[16:01] <wCPO> Yeh, the DO vendor_data is annoying. Adding some magic automount logic
[16:02] <wCPO> rharper: the vendor_data: https://termbin.com/eb0z
[16:14] <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:20] <wCPO> That isn't from DO, but from Hetzner :)
[16:53] <otubo> smoser: thanks!
[16:56] <rharper> wCPO: ah! hehe
[17:19] <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:20] <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:21] <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:22] <blackboxsw> I think we have another feature request in the wild related to trying to better classify log levels for subiquity too
[17:26] <blackboxsw> posted that samish comment on the PR.
=== hjensas|afk is now known as hjensas