ani | any feedback on https://github.com/canonical/cloud-init/pull/4395 ? blackboxsw | 10:22 |
---|---|---|
-ubottu:#cloud-init- Pull 4395 in canonical/cloud-init "net: fix ipv6_dhcpv6_stateful/stateless/slaac configuration for rhel" [Open] | 10:22 | |
bahamat | Hey all, I'm trying to build a debian image with cloud-init and I'm ending up with no resolvers in /etc/resolv.conf. The resolvers are found correctly from the datasource because they're added to /etc/network/interfaces.d/50-cloud-init. | 15:54 |
bahamat | `cloud-init schema --system` returns 'Cloud config schema errors: format-l1.c1: File None needs to begin with "#cloud-config"', whch is not very helpful. | 15:55 |
blackboxsw | bahamat: looks like the datasource cloud-init detected didn't provide user-data or the user-data wasn't able to be parsed and written to the file /var/lib/cloud/instance/user-data.txt. Can you pastebin.opendev.org what `cloud-init query v1` gives you and anything from `egrep 'Tracebcack/ERROR' /var/log/cloud-init.log`? | 15:58 |
bahamat | blackboxsw: There wasn't any user-data passed in, so I guess that would be expected then? | 15:58 |
bahamat | Um, pastebin.opendev.org is NXDOMAIN. | 16:01 |
bahamat | https://pastebin.com/hsEEnJtd | 16:04 |
bahamat | egrep 'Tracebcack/ERROR' returns nothing | 16:04 |
blackboxsw | bahamat: the response from `sudo cloud-init schema --system` is not an ideal message when user-data is empty... I can file a bug if you don't want to. I'd prefer that message is innocuous and tells the person "no/empty user-data" | 16:06 |
bahamat | Yeah, that would be better. But, that's not really my primary concern. | 16:07 |
bahamat | My primary concern is that I have no resolvers, but they are clearly there in the datasource. | 16:07 |
blackboxsw | same. | 16:07 |
blackboxsw | bahamat: what's the following give you: grep 'Applying network' /var/log/cloud-init.log | 16:09 |
bahamat | All the data from the data source related to networking, including this string: "'nameserver', 'address': ['8.8.8.8', '8.8.4.4']" | 16:10 |
bahamat | The resolvconf package is included with the default install. I'm wondering if that's causing a problem? | 16:11 |
bahamat | This doesn't happen on my ubuntu-22 image, but that one has systemd-resolved installed by default. | 16:14 |
bahamat | I can't even fathom the point of either resolvconf or systemd-resolved especially on a server when not having those packages and a proper /etc/resolv.conf just works. | 16:14 |
bahamat | But, whatever, I guess? Maybe I should just try having systemd-resolved installed in the image instead? | 16:15 |
blackboxsw | I'm poking a bit at this bahamat, do you have a cohesive network-config dict that you can paste so I can confirm the net render behavior is it v1 or v2 network config | 16:23 |
bahamat | Like this? | 16:25 |
bahamat | 2023-08-30 16:00:00,883 - stages.py[INFO]: Applying network configuration from ds bringup=True: {'version': 1, 'config': [{'mtu': 1500, 'type': 'physical', 'name': 'net0', 'mac_address': '90:b8:d0:10:f0:78', 'subnets': [{'type': 'static', 'address': '172.25.4.159/24', 'gateway': '172.25.4.1'}]}, {'mtu': 1500, 'type': 'physical', 'name': 'net1', 'mac_address': '90:b8:d0:38:d6:2e', 'subnets': [{'type': 'static', 'address': '172.25.8.94/24'}]}, | 16:25 |
bahamat | {'type': 'nameserver', 'address': ['8.8.8.8', '8.8.4.4'], 'search': []}]} | 16:25 |
bahamat | Sorry if that was too long... | 16:25 |
blackboxsw | thanks I can grab it | 16:25 |
bahamat | I also have a net0 if it makes a difference (probably not...). The only differences are the mac, ip, gateway, and interface name. | 16:26 |
bahamat | Maybe I should spin up an aws one and try to figure out whatever the hell they are doing. | 16:27 |
minimal | bahamat: the cloud-init cc_resolv_conf module (which writes to /etc/resolv.conf) is not activated for Debian | 16:55 |
minimal | so I assume resolvconf is expected to be used instead | 16:56 |
bahamat | OK. That's something at least. | 16:56 |
bahamat | Seems like this is definitely a resolvconf bug then. | 16:57 |
minimal | so else systemd-resolved, depending on the Debian version as (from memory) the latest release does not use /etc/network/interfaces anymore | 16:59 |
blackboxsw | sorry for the delay, Ubuntu writes out netplan network config and relies and netplan to do the right magic to emit /run/systemd/network/10-netplan-eth0.network:DNS=8.8.8.8 which sets the appropriate resolvers | 17:05 |
blackboxsw | and I think the cc_resov_conf module is disabled by default everywhere I believe unless some user-data or system config (/etc/cloud/cloud.cfg.d/*) in the image provides the `manage_resolv_conf: true` | 17:07 |
blackboxsw | and even then, I think it's only alpine and photon distros that actually setup cloud-init by default to run cc_resolv_conf module. | 17:12 |
blackboxsw | yeah cc_resolv_conf module should be redacted from Debian's /etc/cloud/cloud.cfg (so it isn't responsible for writing resolv.conf) as minimal said https://github.com/canonical/cloud-init/blob/main/config/cloud.cfg.tmpl#L131-L133 | 17:17 |
bahamat | minimal: blackboxsw: Ok, turns out I had duplicate entries for `iface lo` in both /etc/network/interfaces and /etc/network/interfaces.d/50-cloud-init. | 17:18 |
bahamat | The dns server config was *only* on iface lo in 50-cloud-init. | 17:18 |
bahamat | When I remove the entry from /etc/network/interfaces, then it seems to work properly. | 17:19 |
bahamat | So, now I just need to cook up an image with that and it should work. | 17:19 |
blackboxsw | ahh ok, so works as designed then, just additional /etc/network/interfaces definition that collided with interfaces.d parts directory? | 17:21 |
minimal | I wonder how the duplicated lo interfaces happened | 17:23 |
bahamat | Well, the way I'm building the image is I do a preseed install, whatever customization I need (which is not much), then clean the image | 17:27 |
bahamat | So that's just from the default debian install, but I need to add that to my clean up so that the only networking config is the one from cloud-init, without any residual config from the image creation. | 17:28 |
blackboxsw | in cloud-init 0.7.9 we used to write on /etc/network/interfaces directly.... but I think that's a decade ago | 17:35 |
minimal | blackboxsw: that's still done when the eni renderer is used | 17:46 |
minimal | (well or a file inside /etc/network/interfaces.d/) | 17:47 |
blackboxsw | right I mean writing /etc/network/interfaces.d/50-cloud-init.cfg is written instead of 0.7.9 writing /etc/network/interfaces directly | 17:47 |
blackboxsw | so if an image were stale and had originally run cloud-init 0.7.9 before upgrading to latest releases. it's possible cloud-init were the cause of that original /etc/network/interfaces file way back when | 17:48 |
blackboxsw | unlikely the source of this case though | 17:49 |
minimal | blackboxsw: apart from 'eni' renderer on Alpine which *does* write /etc/network/interfaces ;-) | 17:49 |
blackboxsw | there's always one flavor :) | 17:51 |
Akila | Hi, I know cloud-init is supported in many flavours of Linux...is Cloud-init supported with ESXi OS..can it customize ESXi OS parameters when installed on a server | 19:04 |
holmanb | Akila: see https://cloudinit.readthedocs.io/en/latest/reference/distros.html | 19:05 |
holmanb | Akila: Not officially supported by upstream cloud-init, but they might provide their own cloud-init support, and adding support to upstream is usually possible | 19:05 |
Akila | Then we need to check with VMware whether esxi is supporting cloud-init? | 19:08 |
holmanb | Akila: Are you talking about an operating system or a hypervisor / cloud? | 19:09 |
Akila | Just ESXi as an OS... | 19:12 |
Akila | like we install rhel.iso on bare metal; I can install esxi on baremetal | 19:12 |
holmanb | Akila: I rephrase: do you intend to run cloud-init on the ESXi operating system or within a VM/container on top of ESXi? | 19:15 |
holmanb | Akila: most would do the later (I think), but it sounds like you are asking for the former | 19:15 |
holmanb | 0 experience with ESXi, so please correct me if I'm wrong | 19:16 |
Akila | yes...on ESXi OS.. not on the VMs created over the esxi hypervisor | 19:18 |
minimal | Akila: VMware don't really expect anyone to modify ESXi OS do they? | 19:25 |
minimal | so how do you expect to make changes and have those changes persist through ESXi updates/upgrades? | 19:26 |
holmanb | Akila: You'll need to check with VMware on support for cloud-init in that way. | 19:27 |
Akila | Here changes I meant, parameters that we can customize upon ESXi OS installation..like timezone, hostname etc..whatever cloud-init supports for rhel today | 20:11 |
Generated by irclog2html.py 2.7 by Marius Gedminas - find it at mg.pov.lt!