[12:46] <ani> e: /etc/ssh/sshd_config.d/50-cloud-init.conf generated by cloud-init I see it is removed using packages/debian/cloud-init.postrm . Since the package manager does not install the conf, could we not have cleaned it up as a part of "cloud-init clean" operation?
[12:47] <ani> blackboxsw
[12:47] <ani> The reason I ask is that for centos/rhel, if we took similar approach, we would have to remove it from the rpm spec file. Instead we could have a common place to remove such conf files
[12:47] <ani> falcojr
[12:48] <ani> Please see https://github.com/canonical/cloud-init/pull/1618
[12:48] -ubottu:#cloud-init- Pull 1618 in canonical/cloud-init "ssh_util: Handle sshd_config.d folder" [Merged]
[14:52] <meena> running tox -e py3 with a freshly patched python…
[15:38] <meena> https://github.com/python/cpython/pull/107813
[15:38] -ubottu:#cloud-init- Pull 107813 in python/cpython "GH-107812: extend `socket`'s netlink support to FreeBSD" [Open]
[18:18] <TimKumina> Hey all, I was wondering, when using a datasource like Ec2, is config in /etc/cloud/cloud.cfg.d still expected to be applied? We're using some write_files in userdata in an Ec2 datasource, but also have one in /etc/cloud/cloud.cfg.d/10-local.cfg. However, the one from /etc/cloud/cloud.cfg.d is never applied and we cannot figure out why, except that
[18:18] <TimKumina> the Ec2 datasource simply overwrites the entire write_files key?
[18:19] <TimKumina> When I do "cloud-init query merged_cfg", I do see the write_files we have locally, but I'm unsure how much value the merged_cfg has in this case.
[18:24] <minimal> I believe that shows merged *system* config, rather than merged user-data
[18:32] <minimal> hmm, I guess they're used as cloud-config even if the files are missing the "#cloud-config" line
[18:34] <TimKumina> That is kinda what I expected, at least
[18:34] <TimKumina> Docs aren't super clear about it :-| Basically, I'm looking for a way to inject "vendor data"
[18:35] <minimal> TimKumina: I think you need to read this page: https://cloudinit.readthedocs.io/en/latest/reference/merging.html
[18:35] <minimal> it might also be affected by which version of cloud-init you're using
[18:36] <minimal> TimKumina: vendor-data? that's provided by the vendor (i.e. AWS/Ec2 in your case)
[18:36] <TimKumina> Running 23.1.1 (Ubuntu provided) and I tried adding the merge_how key to my file as well, didn't seem to make a difference
[18:36] <TimKumina> Well no, this is in premise with Hegel, which acts like Ec2
[18:36] <TimKumina> *on premise
[18:37] <minimal> if you look at that page, with older versions of cloud-init you can see that merged would result in the "latest" write_files replacing any other write_files entries
[18:37] <minimal> that page talks about how you can control the merging behaviour
[18:39] <TimKumina> yes, by adding the merge_how key, but it seems like it's ignored
[18:42] <TimKumina> Ah, found this note: "Note, however, that merge algorithms are not used across configuration types.
[18:42] <TimKumina> As was the case before merging was implemented, user data will overwrite
[18:42] <TimKumina> 'conf.d' configuration without merging."
[18:42] <TimKumina> guess we have to look for another method, then :(
[18:45] <minimal> right, so merging across /etc/cloud/cloud.cfg and any other /etc/cloud/cloud.cfg.d/* files occurs, but not between /etc/cloud/* and provided user-data
[18:46] <minimal> what exactly are you trying to achieve though?
[18:52] <TimKumina> cluster-api provider tinkerbell does not allow overriding over userdata currently, so we're trying to hack some of our custom config either into the image or in some other way
[18:52] <TimKumina> we were hoping that there was a way to merge provided userdata with stuff on disk, but we'll go the nocloud route now and just merge the data ourselves, i think
[18:53] <minimal> you mentionedf write_files, so it's not exactly "user-data" but rather files on the OS you want to modify, so why not modify them when creating the OS image?
[18:54] <TimKumina> because they differ per machine (we need to set the ip address that kubelet listens on by providing a patch file to the kubeadm init process, as it does not support setting an interface instead of an ip address)
[18:55] <TimKumina> we already have per-machine manifests with networking data in cloud-config format, so we were hoping we could simply add it in there
[18:55] <TimKumina> but networking data is handled differently from other data
[18:56] <TimKumina> so this solution works for "network:", but not for "write_files:"
[18:58] <TimKumina> or rather, "network:" is not passed in the user data, which seems a more likely explanation of why this works :)
[18:59] <TimKumina> hm that gives me another idea... if i user a resource that's not passed in the userdata, it should not merge it away...
[19:02] <TimKumina> anyway, thanks for the help! off again
[19:02] <minimal> not sure I understand exactly what you mean
[19:11] <meena> cjp256: https://github.com/python/cpython/pull/107813
[19:11] -ubottu:#cloud-init- Pull 107813 in python/cpython "GH-107812: extend `socket`'s netlink support to FreeBSD" [Open]