| 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:46 |
|---|---|---|
| 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:47 |
| 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] | 12:48 | |
| meena | running tox -e py3 with a freshly patched python… | 14:52 |
| 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] | 15:38 | |
| === TimS is now known as TimKumina | ||
| 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:18 |
| 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:19 |
| minimal | I believe that shows merged *system* config, rather than merged user-data | 18:24 |
| minimal | hmm, I guess they're used as cloud-config even if the files are missing the "#cloud-config" line | 18:32 |
| 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:34 |
| 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:35 |
| 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:36 |
| 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:37 |
| TimKumina | yes, by adding the merge_how key, but it seems like it's ignored | 18:39 |
| 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:42 |
| 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:45 |
| minimal | what exactly are you trying to achieve though? | 18:46 |
| 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:52 |
| 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:53 |
| 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:54 |
| 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:55 |
| TimKumina | so this solution works for "network:", but not for "write_files:" | 18:56 |
| TimKumina | or rather, "network:" is not passed in the user data, which seems a more likely explanation of why this works :) | 18:58 |
| 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... | 18:59 |
| TimKumina | anyway, thanks for the help! off again | 19:02 |
| minimal | not sure I understand exactly what you mean | 19:02 |
| 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] | 19:11 | |
Generated by irclog2html.py 2.7 by Marius Gedminas - find it at mg.pov.lt!