[14:35] Hi! I'm trying to set a custom nameserver for the official cloud images via Cloud-Init however that doesn't seem to work. All settings work just fine, just the nameserver doesn't get applied. [14:35] I'm seeing this issue with the Ubuntu 22.04 Cloud Image. [14:35] Is there any way to debug this? [14:35] Cant find anything in the log # [14:36] iandk: which DataSource are you using? where are you specifying the customer nameserver? [14:38] Network, I'm running Proxmox as a Hypervisor which allows me to set the network parameters. It works just fine with the Debian cloud image, just cant get it to work with ubuntu. [14:38] root@cloudinit:/mnt/cd# cat network-config [14:38] version: 1 [14:38] config: [14:38]     - type: physical [14:38]       name: eth0 [14:38]       mac_address: '06:70:c5:13:04:1e' [14:38]       subnets: [14:38]       - type: ipv6_slaac [14:38]     - type: nameserver [14:38]       address: [14:38]       - '2a03:7900:2:0:31:3:104:161' [14:38]       search: [14:38]       - 'demo.de' [14:41] Ubuntu uses netplan, not sure if Debian still uses /e/n/i or netplan these days [14:41] I think network-config v2 is effectively netplan whereas v1 has to be mapped to netplan [14:42] did you compare the network-config with the resultant netplan? [14:43] Yes, the Netplan config doesn't have anything related to the nameserver. [14:43] The resolv.conf doesn't get updated either. [14:43] I've also tried installing the resolvconf package - but also no luck here [14:43] # This file is generated from information provided by the datasource. Changes [14:43] # to it will not persist across an instance reboot. To disable cloud-init's [14:43] # network configuration capabilities, write a file [14:43] # /etc/cloud/cloud.cfg.d/99-disable-network-config.cfg with the following: [14:43] # network: {config: disabled} [14:43] network: [14:43]     version: 2 [14:43]     ethernets: [14:43]         eth0: [14:43]             dhcp6: true [14:43]             match: [14:43]                 macaddress: 06:70:c5:13:04:1e [14:43]             set-name: eth0 [14:46] the "dhcp6: true" doesn't even seem right as you specified slaac in network-config [14:47] If I recall correctly cloud init uses dhcp6 both for slaac and dhcpv6 [14:47] but not quite sure about that [14:49] If I output the cloud-init.log and filter for my specified nameserver I can see that cloud-init seems to get the right nameserver, it just doesn't apply it for some reason [14:58] did you compare the Debian and Ubuntu cloud-init logs for differences? [15:01] Yes, they seem to be the same [15:04] and is debian using netplan or /e/n/i? [15:08] Debian is using the regular network/interfaces file, so no netplan [15:15] starting to sound like a v1->netplan related issue. Which version of cloud-init is Ubuntu using? [15:23] I'm running version 22.2-0ubuntu1~22.04.2 [17:56] minimal: thanks for fielding the discussion with iandk. I can confirm the behavior in translation for v1 -> netplan via `cloud-init devel net-convert -network-data=netv1.yaml --kind=yaml -D ubuntu -O netplan -d outputdir` [17:56] no nameserver in output. I'll peek today to see what we think should happen here. but looks like a bug [18:28] blackboxsw: I always forget about commands like "cloud-init devel net-convert" lol [18:32] yeah we hide the nasty developer bits under there :) [21:12] falcojr: hi, ive been told at https://bugs.launchpad.net/cloud-init/+bug/1979877 that apparently oracle (my employer) already has an org CLA with you, do i need to do anything before submitting a PR? [21:12] Launchpad bug 1979877 in cloud-init "cloud-init fails with KeyError when nameserver config and matching interface are present" [Undecided, Confirmed] [21:49] yawkat: Excellent. I sent an email off to Legal today to confirm elements of that CLA signing w/ Oracle. As holmanb mentioned. All internal communication shows the company has signed the CLA to allow for upstream commits from oracle developers. From your standpoint opening a PR for cloud-init is good to go. Generally if there were CLA concerns on the submitter, we would block and not land that PR until we sort CLA status. [21:50] (welcome yawkat o/) [21:50] :) [21:51] yawkat: what blackboxsw said, plus still make sure you're following the guidelines in our contributing doc (except for signing the CLA of course) [21:51] https://cloudinit.readthedocs.io/en/latest/topics/contributing.html [21:51] yawkat: From your standpoint, add your github username into ./tools/.github-cla-signers file, we'll confer internally w/ legal and let you know in the PR if you have any other paperwork to allow us to accept the PR. worst case is we might ask that you sign the https://ubuntu.com/legal/contributors/agreement if we need any extra paperwork [21:52] all those steps are documented as falcojr mentioned in the URL (again you may not need to sign the agreement form if we have the ability to vet your github user as a member of Oracle) [21:53] holmanb: falcojr, well I found my snaffu in new-upstream-snapshot and why git-packagebiulder is injecting noisy authorship headers in event d/changelog entry. I'll have a tiny PR against uss-tableflip in a few mins [21:55] okay, thanks. ive created a PR: https://github.com/canonical/cloud-init/pull/1557 – it's just a failing test case, so ive skipped the test running part of the contributing guidelines :) if you need any help with the CLA on our side, just ping me. i can probably get some sort of confirmation from my manager that my github belongs to an oracle employee, the only thing i want to avoid is going through oracle legal since that is bound to take ages and [21:55] probably some business justification messiness. [21:55] Pull 1557 in canonical/cloud-init "Test case for parsing static dns when device is present on system" [Open] [21:56] yawkat: great and thanks! We'll all make sure to sort how an organization member can contribute individually as this case is fairly unique (given the length of time it took to get the organization CLA signed in the first place) [21:57] yea, the last cla i got oracle legal to sign took months, and that was *with* an actual relation to my work. [22:28] holmanb:here's the minor PR that fixes new-upstream-snapshot for a kinetic release if you get a chance today https://github.com/canonical/uss-tableflip/pull/93 [22:28] Pull 93 in canonical/uss-tableflip "gbp: avoid dch authorship headers setting --nomultimaint" [Open] [22:36] blackboxsw: unfortunately probably not going to fit it in today, unfortunately [22:45] holmanb: no worries 'tis late