[01:00] falcojr: This is confirmed as a bug in v21.3 per this comment https://github.com/kubernetes-sigs/image-builder/issues/712#issuecomment-938257637 [01:00] Issue 712 in kubernetes-sigs/image-builder "[Ubuntu] Cloud-init failing with KeyError: id0" [Open] [01:00] (includes a way to repro with a unit test) [01:18] falcojr: I've also identified a patch for the issue, and I'll submit a PR in the morning. The patch is at https://github.com/kubernetes-sigs/image-builder/issues/712#issuecomment-938262835. [01:18] Issue 712 in kubernetes-sigs/image-builder "[Ubuntu] Cloud-init failing with KeyError: id0" [Open] [08:13] blackboxsw, rhansen hey guys I didn't see any messages about cloud-init summit this year. You guys thinking about having one? === Guest6504 is now known as andrewbogott [14:28] I filed https://github.com/canonical/cloud-init/pull/1058 to address https://bugs.launchpad.net/cloud-init/+bug/1946493 [14:28] Pull 1058 in canonical/cloud-init "Fix set-name/interface DNS bug" [Open] [14:28] Launchpad bug 1946493 in cloud-init "Using 'set-name' with interface specific DNS with a v2 network config causes a KeyError" [Undecided, New] [15:14] how to try cloud-init 21.3 on Ubuntu 20.04.3 in AWS ? (I see only 20.04.2 there) [15:38] holmanb: yes i am using the same Openstack version. the Local boot stage is where I am getting the error because the known_mac dict contains only {'00:00:00:00:00:00': 'lo'} [17:36] manuvakery1_: net.get_interfaces() filters out various interface types (vlan/bond/bridge/blacklisted driver/etc) does anything there stand out to you as a possibility? [17:37] If not the best way forward might be to just file a bug (including cloud-init collect-logs output and as much system detail as you can manage) [17:38] otubo: I think we were going to delaying until Mar 2022, but wanted to float that idea by the mailinglist to get concensus on timing. [17:39] holmanb: I will bebug more and update [17:39] *consensus [18:39] falcojr: Thanks for the quick merge1 [18:39] Er, merge! :) [18:48] akutz: I've been using v2 file with set-name for many months now but not with per-interface nameservers, rather using global nameservers so guess its by luck I didn't spot this previously [18:50] Heh. Well, Cluster API Provider for vSphere (CAPV) uses "set-name" to "normalize" interface names. It just so happened this person *also* added the DNS entry feature. When I was running CAPV I basically modeled its guest network config on Cloud-Init's v2 model :) https://github.com/kubernetes-sigs/cluster-api-provider-vsphere/blob/66795d613fe06b4ff7e8f4fe3beb63c4d53c9d4d/api/v1alpha4/types.go#L186-L279 [18:51] Here's a Golang Template for transforming the above data into a valid Cloud-Init v2 network config :) https://github.com/kubernetes-sigs/cluster-api-provider-vsphere/blob/66795d613fe06b4ff7e8f4fe3beb63c4d53c9d4d/pkg/util/constants.go#L19-L89 [18:52] minimal: But I never caught this either, because I was also always using global nameservers, so what can ya do? I'm just glad I had the epiphany about the set-name. That seemed suspicious to me since there was a KeyError. [18:53] I guess if you define per-interface nameservers for more than 1 interface that its supposed to use resolvconf to handle this? [18:56] I mean, I've no clue. Looking at netplan I think they expect one interface is the default route and you set them there? https://netplan.io/reference/#common-properties-for-all-device-types [19:01] Hey just wanted some guidance on this error [19:02] this morning after reboot clud-init gave: azure.py[ERROR]: Could not crawl Azure metadata: 'Dat [19:02] aSourceAzure' object has no attribute 'failed_desired_api_version' [19:03] after that it reconfigured everything as it it were firstboot [20:01] Nico1: can you run `cloud-init --version` [20:03] sure /usr/bin/cloud-init 21.3-1-g6803368d-0ubuntu1~18.04.3 [20:08] thanks Nico1: Can you please file a bug at https://bugs.launchpad.net/cloud-init/+filebug and attach the tar.gz from `cloud-init collect-logs to help triage here? Ok so you are ubuntu bionic Azure. That attribute was added in 21.1-19 which was released in March I think. [20:08] I'm guessing you can from a version earlier that 21.1-19 straight to 21.3.1, but your /var/log/cloud-init.log will tell us better [21:14] will do thanks, on the other hand I validated that package was updated on october, but from v21.2