[08:28] Hello Odd_Bloke hope you remember me from yesterday. I had a question regarding ssh host key keys that I think get generated too late. I am sorry for leaving in the middle of the conversation but my isp has failed on me and couldn't log back in. Do you have any idea what I can do to have my machine print the keys? Thanks for the help [08:31] These are the logs I have on hand: https://pastebin.ubuntu.com/p/DrZ84SWsfM/ & https://pastebin.ubuntu.com/p/dk4hMqsCVX/ [16:05] Hi all ... thought I'd ask about how PS #745 is looking (https://github.com/canonical/cloud-init/pull/745). If there's anything needed from me to help move it forward I'm happy to help. Thanks! [16:13] Odd_Bloke: in case testing1818282 returns, it looks to me like, the instance 1) already has existing host keys; they get deleted in the log 2) the instnace does not invoke ssh-keygen, which could be cause of user-data config , or the RHEL image it's running may generate ssh-keys via the ssh-keygen.service; in which case maybe that is running (or not running) at the correct time; [16:15] beantaxi: it's on my list to review; my quick take is that each of those scripts are 99% identical other than the name and file; I would like to see a common handle implementation that each of those script files import and use, passing in the variable name/path; [16:33] rharper: Aha, didn't know about that service, that's really handy info. We'll see if I get to use it. :p [16:37] https://github.com/canonical/cloud-init/pull/750 is open, clarifying how netplan passthrough works; I couldn't find anywhere that we documented it previously. [16:44] Odd_Bloke: thanks for 750, I'll review; I myself have had to re-read the code a few times to recall how we keep the imported config around and detect v2 pass-through to write out the original [16:45] Odd_Bloke: that PR came about from a discussion I'd had with the reporter on here over the holiday period [16:46] I was pointing out to him that just because what he was doing with netplan currently worked in c-i was no guarantee that it would continue to work as it wasn't a documented c-i network-v2 configuration [16:46] plus the issue of course of it not working for e/n/i and other renders [16:49] minimal: Aha, right, I hadn't put the IRC backlog and bug together; thanks for helping them out! [16:50] at the time it surprises me to see him using the "from:" value as I've used static routes with e/n/i and had not seen that before [16:51] rharper: I've just seen https://paste.ubuntu.com/p/CWcp88S2QM/ in a focal cloud-init KVM run; does that look like the same kernel issue we've been seeing from time-to-time? [16:52] Odd_Bloke: that looks new to me; [16:54] the stack track looks KVM related; I would guess either the host OOMed or otherwise couldn't fill the memory request; so highly memory contention; [16:59] Odd_Bloke: looks like this, https://github.com/torvalds/linux/commit/2a266f23550be997d783f27e704b9b40c4010292 ; which landed in 5.11, not sure if kernel team has that in 5.4.1 in focal ; [17:07] rharper: Sounds reasonable. I can do that today. Thanks for the feedback! [17:07] beantaxi: cool! [17:08] beantaxi: I also elaborated on the PR directly, please look at those comments as well [17:20] rharper: That looks like it landed in v4.15, if I'm reading the GH tags right? [17:35] Odd_Bloke: yeah, I don't fullly understand what that 4.15 tag means; if it did land in 4.15, how did it get into 5.4, and why also 5.11 [17:36] I believe that displays the tags which include this commit in their history; so I think it landed in 4.15 (and is therefore present in every subsequent tag). [17:42] We're also seeing https://paste.ubuntu.com/p/N395dZxnGz/ on groovy. [17:57] rharper: Yes I read through your comments and smosers too. They're great: politeful and respectful but very clear. Much appreciated! === ijohnson is now known as ijohnson|lunch [19:17] rharper: Thanks for the review. :) === vrubiolo1 is now known as vrubiolo === ijohnson|lunch is now known as ijohnson [22:02] o/ [22:04] I am using cloud-init with AWS EC2 deployed via CloudFormation. If I change the cloud-config can I get it to apply on an CloudFormation update? For example, I want to update the contents of a file created via write_files. [22:05] wyoung: on an existing instance? or new instance? [22:06] rharper: existing. [22:07] by default, cloud-init won't re-run write_files config on the same instance; you can force a particular module to run with: cloud-init single --name write_files --frequency always ; [22:08] rharper: I would add that to the runcmd section? [22:08] and run it manually for the existing instance? [22:12] you need to run that command on the instance itself (ie, ssh into and run that command) [22:12] wyoung: ^ [22:13] rharper: And for new instances (after I add in that command to runcmd) will it write files on a change? [22:13] Or do I need to manually run the command again after any change/. [22:13] not really; manually need to run that any time it changes; [22:15] I'm not sure how CloudFormation works; but ideally; you could set up some http long poll against the CF config URL; and on-change, run an update; but that's just not in place; any given cloud-init config moodules (run_cmd, users, packages, etc...) may not be idempotent; so it's not clear what cloud-init should do if the user-data config changed ... [22:16] for something like a write_files where you know you want to update a particular file, you may want to set up some sort of watch on the config URL, and on change run the command; [22:16] less effort but not as dynamic would be put that into a cron job which runs every so often