=== logan_ is now known as logan- [08:36] Hello, any known problems/difficulties with the [`ssh_key`](https://cloudinit.readthedocs.io/en/latest/topics/examples.html#configure-instances-ssh-keys) parameter in cloud-init? I am trying to use it in a AWS EC2 instance managed via CloudFormation and the keys in `/etc/ssh` are fresh ones instead of the ones I provided in the cloud-init file. [09:07] Nevermind, now it works! [09:08] cedricvr: what fixed it? [09:08] No idea what I did. Maybe just recreate the CloudFormation stack instead of “updating” it [09:09] Yesterday evening I tried using this parameter and it didn't seem to work, and today tried again and this time it works. The frustrations of infrastructure management ... [11:07] rharper: any reason why you opted for `try-restart' and not `reload'? [11:08] Odd_Bloke: blackboxsw if you guys have a time to merge my PR that would be awesome :-) https://github.com/canonical/cloud-init/pull/70 [11:10] otubo: because, if nm isn't running yet, it won't do anything [11:12] meena: right right, good point. [11:14] meena: and I assume `reload' will return error in case the service is not running. [11:14] otubo: try it out.?? [11:15] meena: :) cnofirmed, it will return error. [14:49] otubo: meena 's spot on; =) [14:54] rharper: the way things are handled systemd-wise, I think I'll have to create new directories like ./systemd/[system,cloud-init.service.d], move the systemd files into system and the drop-in into cloud-init.service.d. And fix all the scripts that refer to them. [14:54] rharper:sounds good? [14:55] otubo: for drops, I would suggest packaging changes in the rpm vs. upstream; and drop-ins can go out in /etc/systemd/system/ (which already exists) you will need to mkdir the cloud-init.service.d and the conf file [14:56] otubo: long term (upstream), a PR to use post-commands in sysconfig renderer to try-restart network-manager (if we've written out a nm conf file) will remove the need for the drop-in [14:58] rharper: Hm, ok, then. I'm gonna do a downstream-only fix then, and will work on the renderer later. [14:58] +1 [14:59] that seems the fastest path (and it can work for older releases if you don't plan on backporting the fix) [16:41] could you take a look at https://github.com/canonical/cloud-init/pull/62? The PR should be harmless, and it brings the support for NetBSD. And it's a dependency for OpenBSD. Pleaaaaase :-) [17:26] Goneri: will give a pass now [17:31] so I'm a bit confused. I dropped a sample override config in /etc/cloud/cloud.cfg.d/defaults.cfg, which included things like write_file invocation. this seems to work just fine when the instance is created, but only that first time [17:32] ananke: each cloud-init config module has a default frequency; runcmd is per-instance; which means the first time it's run only; [17:32] shouldn't it be invoked with every boot? /etc/cloud/cloud.cfg lists 'write-files' module under cloud_init_modules section [17:32] rharper: ahh, so the frequency is per module [17:32] yes [17:33] doh, that would explain. thank you. I see it documented now [17:33] if we want every boot https://cloudinit.readthedocs.io/en/latest/topics/modules.html#scripts-per-boot [17:33] for scripts, and you're modifying the image, it's likely easiest to drop them into /var/lib/cloud/scripts/per-{boot,instance,once} [17:33] selecting the frequency you want [17:33] by directory [17:34] that dir is invoked via run-parts (man 8 run-parts) [17:34] yeah, I was already leveraging those locations, but I saw how easy write_files was for a small config file, I figured I would use that in this case. back to the drawing board [17:35] is there a quick reference matrix that shows each module and its default frequency? [17:36] ananke: no, but that's a great idea to document; it's specified in the config module, cc_.py [17:37] you'll see 'frequency' attribute; the default without a value is 'per-instance' [17:37] https://cloudinit.readthedocs.io/en/latest/topics/modules.html#write-files [17:37] it is documented though (just not all in a single table) [17:38] https://cloudinit.readthedocs.io/en/latest/topics/modules.html as a list of the modules [17:38] yep, thank you. was just going down that page and searching for 'Module frequency' [17:40] there is a way to modify the frequency of a module, but not from user-data; as cloud-init reads system config /etc/cloud/* to determine how often to call specific modules; and even that there isn't an easy way to modify the value in config; (the modules list accept a single list of names, or a tuple of name, freq) [18:35] thanks Goneri for https://github.com/canonical/cloud-init/pull/62/files and meena for review too. suggestions posted [18:35] <- errand [18:36] 15:49 <@rharper> otubo: meena 's spot on; =) ⬅️ this statement could be generalised, but let's not stroke my ego too much [18:39] blackboxsw: have you had time to mull over robjo's networking refactoring (yupp, it's his now ;)? [19:03] heh. I did a bit and wanted to capture some thoughts today, I've freed up a bit now that SRU process has started [19:08] meena: =) [20:53] ahosmanMSFT: hiya, just a note that we've queued your Azure instance-id byte-swap fix for SRU testing in Ubuntu Xenial, Bionic or Eoan. steps to manually test on whatever affected instance types you had access to would be here: https://cloudinit.readthedocs.io/en/latest/topics/debugging.html#manual-sru-verification-procedure [20:53] I'll be testing more frequent deployment mechanisms on Azure today. [20:58] blackboxsw, thanks for the review :-) [20:59] no problem Goneri [21:01] i only discovered one mthod that was already implemented in distro/__init__.py [21:02] and only because i had read the code recently.