[02:33] gschanuel: I have never tried what you're talking about, but the cloud-init vmware datasource docs talk about setting the encoding type for userdata/metadata. I don't see that in the commands you linked above. [02:34] gschanuel: https://cloudinit.readthedocs.io/en/latest/topics/datasources/vmware.html?highlight=.encoding [02:46] New to cloud-init here. How can I "validate" a configuration file without booting a new instance for it? [02:56] found my answer :) [02:56] `cloud-init devel schema --config-file file` === IchabodCrane is now known as WrathOfAchilles [14:45] I just filed https://bugs.launchpad.net/cloud-init/+bug/1949371 [14:45] Launchpad bug 1949371 in cloud-init "'Unable to find a system nic' if openstack lists down ports in json config" [Undecided, New] [14:46] This is currently breaking most of ppc64el scalingstack cloud [14:46] Arguably the cloud might be broken too [14:46] I'm trying to hack an image together that does not error out here, but it's hard [14:46] As I first need to get a server booted [17:24] Thanks juliank: I think we'd need to see what network_data.json is representing to the instance. As the network JSON there will instruct cloud-init what to do with all interfaces. Since OpenStackLocal datasource reads networkdata using the link-local address http://169.254.169.254/openstack/2018-08-27/network_data.json that data should be available to us into the system via console or ssh. [17:25] One way we might do that is using write_files: to emit /etc/netplan/50-cloud-init.yaml for only the known NIC you expect to be up and re-run netplan apply via something like this https://pastebin.canonical.com/p/Jx3cQVDgs7/ [17:26] then you can ssh into the instance I hope and `cloud-init query ds.network_json` to see what openstack told us [17:27] alternative would be to try logging into the console via the novnc url (which I think you said was unavailable on this openstack deployment) openstack console url show . on my stack I've got the ability to launch a browser to the URL provided to login without SSH [17:48] looks like the internet broke CI again. I see it on brett's and my failing PRs https://github.com/canonical/cloud-init/pull/1090/checks?check_run_id=4070158851 [17:48] Pull 1090 in canonical/cloud-init "Add LXD to datasource list" [Open] [18:27] @blackboxsw - it looks like at least one of the failures can be fixed by cherry picking a test dependency from main [18:31] scratch that, I didn't test well enough locally [20:09] looks to me like it may have been a spurious error my next pull is running fine https://app.travis-ci.com/github/canonical/cloud-init/builds/240972200 [20:14] falcojr: lxd_container integration test and lxd_vm tests have passed on my PR [20:43] blackboxsw: https://github.com/canonical/cloud-init/pull/1040 merged! [20:43] Pull 1040 in canonical/cloud-init "Add LXD datasource" [Merged] [20:43] woo hoo! coffee break. [21:24] blackboxsw: upstream release PR when ready https://github.com/canonical/cloud-init/pull/1091 [21:24] Pull 1091 in canonical/cloud-init "Release 21.4" [Open] [22:46] falcojr: grabbing it now [23:12] falcojr: approved the PR, but integration tests have yet to run on 21.4 yet now that LXD datasource is committed. I want to get a +1 from the daily integration runs @ https://jenkins.ubuntu.com/server/job/cloud-init-integration-lxd_container-impish-daily/ and https://jenkins.ubuntu.com/server/job/cloud-init-integration-lxd_vm-impish-daily/ before we sign and push the upstream version