/srv/irclogs.ubuntu.com/2020/01/17/#cloud-init.txt

=== logan_ is now known as logan-
cedricvrHello, 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.08:36
cedricvrNevermind, now it works!09:07
meenacedricvr: what fixed it?09:08
cedricvrNo idea what I did. Maybe just recreate the CloudFormation stack instead of “updating” it09:08
cedricvrYesterday 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 ...09:09
otuborharper: any reason why you opted for `try-restart' and not `reload'?11:07
otuboOdd_Bloke: blackboxsw if you guys have a time to merge my PR that would be awesome :-) https://github.com/canonical/cloud-init/pull/7011:08
meenaotubo: because, if nm isn't running yet, it won't do anything11:10
otubomeena: right right, good point.11:12
otubomeena: and I assume `reload' will return error in case the service is not running.11:14
meenaotubo: try it out.??11:14
otubomeena: :) cnofirmed, it will return error.11:15
rharperotubo: meena 's spot on;  =)14:49
otuborharper: 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
otuborharper:sounds good?14:54
rharperotubo: 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 file14:55
rharperotubo: 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-in14:56
otuborharper: Hm, ok, then. I'm gonna do a downstream-only fix then, and will work on the renderer later.14:58
rharper+114:58
rharperthat seems the fastest path (and it can work for older releases  if you don't plan on backporting the fix)14:59
Gonericould 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 :-)16:41
blackboxswGoneri: will give a pass now17:26
anankeso 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 time17:31
rharperananke: each cloud-init config module has a default frequency; runcmd is per-instance; which means the first time it's run only;17:32
anankeshouldn't it be invoked with every boot? /etc/cloud/cloud.cfg lists 'write-files' module under cloud_init_modules section17:32
anankerharper: ahh, so the frequency is per module17:32
rharperyes17:32
anankedoh, that would explain. thank you. I see it documented now17:33
blackboxswif we want every boot https://cloudinit.readthedocs.io/en/latest/topics/modules.html#scripts-per-boot17:33
rharperfor 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
rharperselecting the frequency you want17:33
rharperby directory17:33
rharperthat dir is invoked via run-parts (man 8 run-parts)17:34
anankeyeah, 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 board17:34
anankeis there a quick reference matrix that shows each module and its default frequency?17:35
rharperananke: no, but that's a great idea to document;  it's specified in the config module, cc_<modname>.py17:36
rharperyou'll see 'frequency' attribute; the default without a value is 'per-instance'17:37
rharperhttps://cloudinit.readthedocs.io/en/latest/topics/modules.html#write-files17:37
rharperit is documented though (just not all in a single table)17:37
rharperhttps://cloudinit.readthedocs.io/en/latest/topics/modules.html  as a list of the modules17:38
anankeyep, thank you. was just going down that page and searching for 'Module frequency'17:38
rharperthere 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)17:40
blackboxswthanks Goneri for https://github.com/canonical/cloud-init/pull/62/files and meena  for review too. suggestions posted18:35
blackboxsw<- errand18:35
meena15:49 <@rharper> otubo: meena 's spot on;  =) ⬅️ this statement could be generalised, but let's not stroke my ego too much18:36
meenablackboxsw: have you had time to mull over robjo's networking refactoring (yupp, it's his now ;)?18:39
blackboxswheh. I did a bit and wanted to capture some thoughts today, I've freed up a bit now that SRU process has started19:03
rharpermeena: =)19:08
blackboxswahosmanMSFT: 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-procedure20:53
blackboxswI'll be testing more frequent deployment mechanisms on Azure today.20:53
Goneriblackboxsw, thanks for the review :-)20:58
blackboxswno problem Goneri20:59
meenai only discovered one mthod that was already implemented in distro/__init__.py21:01
meenaand only because i had read the code recently.21:02

Generated by irclog2html.py 2.7 by Marius Gedminas - find it at mg.pov.lt!