[08:36] <cedricvr> 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] <cedricvr> Nevermind, now it works!
[09:08] <meena> cedricvr: what fixed it?
[09:08] <cedricvr> No idea what I did. Maybe just recreate the CloudFormation stack instead of “updating” it
[09:09] <cedricvr> 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] <otubo> rharper: any reason why you opted for `try-restart' and not `reload'?
[11:08] <otubo> 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] <meena> otubo: because, if nm isn't running yet, it won't do anything
[11:12] <otubo> meena: right right, good point.
[11:14] <otubo> meena: and I assume `reload' will return error in case the service is not running.
[11:14] <meena> otubo: try it out.??
[11:15] <otubo> meena: :) cnofirmed, it will return error.
[14:49] <rharper> otubo: meena 's spot on;  =)
[14:54] <otubo> 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] <otubo> rharper:sounds good?
[14:55] <rharper> 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] <rharper> 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] <otubo> rharper: Hm, ok, then. I'm gonna do a downstream-only fix then, and will work on the renderer later.
[14:58] <rharper> +1
[14:59] <rharper> that seems the fastest path (and it can work for older releases  if you don't plan on backporting the fix)
[16:41] <Goneri> 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] <blackboxsw> Goneri: will give a pass now
[17:31] <ananke> 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] <rharper> 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] <ananke> shouldn't it be invoked with every boot? /etc/cloud/cloud.cfg lists 'write-files' module under cloud_init_modules section
[17:32] <ananke> rharper: ahh, so the frequency is per module
[17:32] <rharper> yes
[17:33] <ananke> doh, that would explain. thank you. I see it documented now
[17:33] <blackboxsw> if we want every boot https://cloudinit.readthedocs.io/en/latest/topics/modules.html#scripts-per-boot
[17:33] <rharper> 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] <rharper> selecting the frequency you want
[17:33] <rharper> by directory
[17:34] <rharper> that dir is invoked via run-parts (man 8 run-parts)
[17:34] <ananke> 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] <ananke> is there a quick reference matrix that shows each module and its default frequency?
[17:36] <rharper> ananke: no, but that's a great idea to document;  it's specified in the config module, cc_<modname>.py
[17:37] <rharper> you'll see 'frequency' attribute; the default without a value is 'per-instance'
[17:37] <rharper> https://cloudinit.readthedocs.io/en/latest/topics/modules.html#write-files
[17:37] <rharper> it is documented though (just not all in a single table)
[17:38] <rharper> https://cloudinit.readthedocs.io/en/latest/topics/modules.html  as a list of the modules
[17:38] <ananke> yep, thank you. was just going down that page and searching for 'Module frequency'
[17:40] <rharper> 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] <blackboxsw> thanks Goneri for https://github.com/canonical/cloud-init/pull/62/files and meena  for review too. suggestions posted
[18:35] <blackboxsw> <- errand
[18:36] <meena> 15:49 <@rharper> otubo: meena 's spot on;  =) ⬅️ this statement could be generalised, but let's not stroke my ego too much
[18:39] <meena> blackboxsw: have you had time to mull over robjo's networking refactoring (yupp, it's his now ;)?
[19:03] <blackboxsw> 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] <rharper> meena: =)
[20:53] <blackboxsw> 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] <blackboxsw> I'll be testing more frequent deployment mechanisms on Azure today.
[20:58] <Goneri> blackboxsw, thanks for the review :-)
[20:59] <blackboxsw> no problem Goneri
[21:01] <meena> i only discovered one mthod that was already implemented in distro/__init__.py
[21:02] <meena> and only because i had read the code recently.