[10:22] <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]
[15:54] <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:55] <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:58] <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?
[16:01] <bahamat> Um, pastebin.opendev.org is NXDOMAIN.
[16:04] <bahamat> https://pastebin.com/hsEEnJtd
[16:04] <bahamat> egrep 'Tracebcack/ERROR' returns nothing
[16:06] <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:07] <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:09] <blackboxsw> bahamat: what's the following give you: grep 'Applying network' /var/log/cloud-init.log
[16:10] <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:11] <bahamat> The resolvconf package is included with the default install. I'm wondering if that's causing a problem?
[16:14] <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:15] <bahamat> But, whatever, I guess? Maybe I should just try having systemd-resolved installed in the image instead?
[16:23] <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:25] <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:26] <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:27] <bahamat> Maybe I should spin up an aws one and try to figure out whatever the hell they are doing.
[16:55] <minimal> bahamat: the cloud-init cc_resolv_conf module (which writes to /etc/resolv.conf) is not activated for Debian
[16:56] <minimal> so I assume resolvconf is expected to be used instead
[16:56] <bahamat> OK. That's something at least.
[16:57] <bahamat> Seems like this is definitely a resolvconf bug then.
[16:59] <minimal> so else systemd-resolved, depending on the Debian version as (from memory) the latest release does not use /etc/network/interfaces anymore
[17:05] <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:07] <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:12] <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:17] <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:18] <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:19] <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:21] <blackboxsw> ahh ok, so works as designed then, just additional /etc/network/interfaces definition that collided with interfaces.d parts directory?
[17:23] <minimal> I wonder how the duplicated lo interfaces happened
[17:27] <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:28] <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:35] <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:46] <minimal> blackboxsw: that's still done when the eni renderer is used
[17:47] <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:48] <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:49] <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:51] <blackboxsw> there's always one flavor :)
[19:04] <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:05] <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:08] <Akila> Then we need to check with VMware whether esxi is supporting cloud-init?
[19:09] <holmanb> Akila: Are you talking about an operating system or a hypervisor / cloud?
[19:12] <Akila> Just ESXi as an OS...
[19:12] <Akila> like we install rhel.iso on bare metal; I can install esxi on baremetal
[19:15] <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:16] <holmanb> 0 experience with ESXi, so please correct me if I'm wrong
[19:18] <Akila> yes...on ESXi OS.. not on the VMs created over the esxi hypervisor
[19:25] <minimal> Akila: VMware don't really expect anyone to modify ESXi OS do they?
[19:26] <minimal> so how do you expect to make changes and have those changes persist through ESXi updates/upgrades?
[19:27] <holmanb> Akila: You'll need to check with VMware on support for cloud-init in that way.
[20:11] <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