[01:28] <pasha-19> I have recently discovered cloud-init,  It appears to have a great deal of potential.  However; from what I have read in the documentation there appear to be considerable gaps.  Part of that discovery came from attempting to merge the default raspberry pi ubuntu meta-data. user-data and network-config files with a set created by rpi-imager.
[01:28] <pasha-19> Then comparing the contents to the Cloud-init: Config Examples determining that there appear to be numerous hierarchical groups in each file in the ubuntu config that do not appear in the Cloud-init examples.  From these investigations including reading considerable portions of the https://cloudinit.readthedocs.io/en/latest/; I am coming up with
[01:28] <pasha-19> more questions than answers. I wrote about a 7,000 character explanation of what I learned and what I do not understand.  Iss\ there any interest in reviewing my observations to possibly simplify a beginner's  entry into using what appears to be a powerful tool?
[01:41] <pasha-19> Good luck with what you are doing; I believe it really has potential.  Perhaps one has to read the source code to determine the answers  I can probably muddle through doing about 1/2 the job in cloud-init then switching to bash scripts where I am slightly less of a novice to complete the process..
[01:41] <pasha-19> bye
[09:07] <haroon> hello everyone, I'm trying to get cloud-init to setup my network on creation of the vm. I have the following in the user-data https://paste.debian.net/plain/1242650 , however the nameserver and gateway are not set. I specified the actual name of the interface, because I didn't understood the documentation, if this can be random. I hope someone can educate me on my mistake or point me in the
[09:07] <haroon> right direction.
[09:29] <aciba> Hello haroon. According to the doc here: https://cloudinit.readthedocs.io/en/latest/topics/network-config.html, user-data cannot change an instance's network configuration. You could use a system config file or a kernel command if you want to override the Datasource's network metadata.
[16:17] <blackboxsw> pasha-19, I know we missed you yesterday. If you end up dropping back into channel in the future, we are definitely interested in doc gaps that help in the usability and reducing the ramp-up time for cloud-init consumers. Common pain points/suggestions/contributions are always welcome.
=== esv_ is now known as esv
[19:30] <dch> how does cloudinit decide which user to "install" ssh pubkeys into?
[19:30] <dch> I'm not clear if I can/should put some specific config into the image itself, or if this is entirely driven from retrieved metadata
[19:39] <dch> AFAICT this can be dropped in /etc/cloud.cfg in a distro-specific section at the end, for example
[19:46] <minimal> dch: it doesn't decide, it does what you (i.e. the user-data) tells it to do
[19:47] <dch> minimal: fine, semantics. IoW the default user setting is taken from the cloud.cfg if present, and can be overridden or extended via user-data? 
[19:49] <minimal> dch: its all documented, use "ssh_authorized_keys" either at the top-level or within a "users:" section
[19:49] <minimal> https://cloudinit.readthedocs.io/en/latest/topics/modules.html#ssh
[19:49] <minimal> https://cloudinit.readthedocs.io/en/latest/topics/modules.html#users-and-groups
[19:56] <dch> minimal: thanks, got it working now. only need to figure out best way of including this into the custom build.
[19:59] <minimal> dch: well you could add a "users:" section to the /etc/cloud/cloud.cfg file of the disk image
[20:00] <minimal> depends also which user you want to do this for...
[20:01] <dch> minimal: yes this is what I have done. What was (initially) confusing is that the cloud.cfg file has a `users:\n  -default` section at the top, but its actually provided by the distro settings at the end
[20:03] <Rick41> hello everyone, I have a question regarding cloud-init, is there a way to change the directory layout? instead of use /var/lib/cloud, use any other directory?
[20:03] <minimal> Rick41: why?
[20:04] <minimal> dch: you might also have an issue if any user-data also has a "users:" section
[20:07] <Rick41> it seems security recommendations are adding noexec to /var, so runcmd won't work from there.
[20:08] <minimal> Rick41: not sure if its easy to change, but if you can change it then you'll end up with a non-standard directory layout which will at the very least confuse people
[20:09] <Rick41> if isn't as easy as changing the config file, then i wont do it.
[20:18] <minimal> Rick41: there is a cloud_dir setting in /etc/cloud/cloud.cfg that is normally set to "/var/lib/cloud"
[20:18] <minimal> however I see some hardcoded references to /var/lib/cloud in various parts of the cloud-init source code
[20:27] <blackboxsw> Rick41: seems reminiscent of this bug https://bugs.launchpad.net/cloud-init/+bug/1962343 
[20:27] <ubottu> Launchpad bug 1962343 in cloud-init "VMs hardening with the noexec option in /tmp and /var/tmp which is causing issues to get an IP with cloud-init , reason why the VM takes like 25 min to start" [High, Triaged]
[20:28] <Rick41> yes, thanks!
[20:28] <Rick41> also found this one: https://bugs.launchpad.net/cloud-init/+bug/1839899
[20:28] <blackboxsw> minimal: if we have vestigial hardcoded /var/lib/cloud references called at runtime, that feels like a bug too. I see some of the references you are alluding to as well.
[20:28] <ubottu> Launchpad bug 1839899 in cloud-init "cloud-init will not run user-data scripts when /var filesystem is mounted with the noexec flag" [Medium, Triaged]
[20:33] <minimal> blackboxsw: yeah I just did a quick recursive grep on the source but didn't doublecheck
[20:34] <blackboxsw> thx for the reference Rick41 I tied the two bugs together with a comment on 1839899 as well so we know to handle both.
[20:35] <blackboxsw> minimal: +1 same fgrep FTW. looks like reporting logic has as util.fetch_ssl_details() calls that don't observe the "cloud_dir" config directive.
[20:35] <blackboxsw> and various datasources and utilities that need cleaning up too :/
[20:36] <blackboxsw> I'm filing a bug on cloud_dir specifically. That config option should be globally honored
[20:36] <minimal> I guess the only way to deal with those sort of things is to have testcases that configure everything configurable :-)
[20:36] <blackboxsw> +10
[20:37] <blackboxsw> pytest.mark.parametrize for the win
[20:37] <minimal> cloud-init-chaos-monkey perhaps? ;-)
[20:39] <blackboxsw> all said fixing cloud_dir won't solve the /var/tmp issue for dhclient :/ Need a different bit of work for that to sort cloudinit/temp_utils.py `_tempfile_dir_arg(..., needs_exe=True)` as that defaults to /var/tmp
[20:39] <blackboxsw> and is not configurable
[23:25] <blackboxsw> filed https://bugs.launchpad.net/cloud-init/+bug/1976564 related to cloud_dir not being handled everywhere. this "should" be the right way to handle a noexec /var/lib/cloud filesystem I think. 
[23:25] <ubottu> Launchpad bug 1976564 in cloud-init "cloud-config: cloud_dir setting not honored globalling by cloud-init" [High, Triaged]
[23:25] <blackboxsw> Rick41: ^ FYI for tracking in case you end up adapting cloud_dir setting /var/lib/cloud