=== cpaelzer__ is now known as cpaelzer
[09:49] <Max0815> hey, short question. Is it possible to read a value for a key of a cloud-config file from a different file? Like I want to read ssh_authorized_keys from a file rather than specifying it in the cloud-config file.
[09:51] <Max0815> would be nice to reuse the code. If I want to put my cloud-config file under version control I obviously don't want to put stuff like passwords under version control.
[10:03] <Max0815> So far I guess using a template, putting that under version control and generating the cloud-init dynamically will solve my use case.
[10:07] <tribaal> Max0815: that is one option. Another option depending on your use case could be to execute an aribtrary command during cloud-init that will do the thing you need (read from a remote list of authorized keys or whatever).
[10:13] <Max0815> tribaal: thx, didn't think about that. However, creating a template looks a bit easier. If I were to retrieve data from a remote I would need to provide a mechanism to access the remote in the cloud init.
[10:14] <tribaal> oh yes, of course it entirely depends on your use case :)
[13:35] <ananke> what's the easiest way to tell which cloud-init module is still running? I have cloud-init status showing 'running', but I can't figure out what's not finished
[13:37] <blackboxsw> ananke: cloud-init status --long. or check for stages that have no start and stop time in /run/cloud-init/status.json
[13:37] <blackboxsw> I bet it's something to the with something introducing a systemd dependency chain issue. (that's what typically blocks cloud-init from finishing
[13:37] <ananke> interesting: DataSourceEc2Local
[13:38] <blackboxsw> https://unix.stackexchange.com/questions/193714/generic-methodology-to-debug-ordering-cycles-in-systemd
[13:39] <ananke> so long story short, we're in the process of using packer & cloud-init to make new AMIs for our educational platform. we have stuff working on ubuntu 18.04, and took that over to kali. this appears to be the first hurdle to overcome
[13:41] <ananke> while the source kali has cloud-init, and looks like it sets up stuff as expected, it never finishes. we use '/usr/bin/cloud-init status --wait' as a stage in the build, to make sure things are up and running, but clearly something is waiting for AWS info
[14:17] <blackboxsw> today I learn about kali :) amanke if you grab /var/log/cloud-init.log it'd likely show you specifically what cloud-init is looping on `cloud-init analyze blame` may also give you some info. (though I can't recall if that doesn't help you if you are still in an unfinished state for cloud-init)
[18:28] <fredlef1> @rharper: I'm just circling back to PR-229
[18:29] <fredlef1> After reading your doc, I think a detail is escaping me.
[18:30] <Odd_Bloke> fredlef1: rharper is out until Monday, FYI, so commenting on the PR might be a better way to be sure to get a response.
[18:30] <fredlef1> good to know. Thanks
[19:39] <Odd_Bloke> A very small precursor to my Oracle work to sort the imports: https://github.com/canonical/cloud-init/pull/266
[19:43] <blackboxsw> Odd_Bloke: approved, needs CI
[19:51] <Odd_Bloke> Thanks, landed.
[21:55] <blackboxsw> ok put up Focal to prioritize netplan above ENI rendering https://github.com/canonical/cloud-init/pull/267
[21:55] <blackboxsw> for Ubuntu
=== waxfire9 is now known as waxfire