[00:47] hi all, having difficulty figuring out the cloud-init ecosystem. As far as I can tell, there's a core set of features that the cloud-init utility itself provides, along with metadata that individual cloud providers expose as a datasource to cloud-init. If I were to just download some random cloud image of a Linux-based distribution, where would i begin to dissect what is supported? For example, [00:47] there is a note here: https://cloudinit.readthedocs.io/en/latest/reference/network-config.html that says PhotonOS disabled fallback networking. Where does Photon define that? [00:47] additionally, to figure out what metadata is provided per-cloud provider, would I just consult their docs (assuming the docs actually document this) [01:18] greeb: let's backtrack - what are you trying to achieve? [01:19] you want to create a VM on a particular Cloud Provider? [01:25] I'm running terra(grunt|form) using the libvirt provider. It works well for quickly spinning up local VMs and I am starting to prefer it to vagrant. there is a templatized network configuration that terragrunt consumes. Here's the pastebin: https://pastebin.com/a5RU21A7 . The cloud I'm using is an official Ubuntu xenial image. My question is why does that network drop-in simply work. [01:25] "drop-in"? [01:26] so the cloud disk image (not "cloud") you're using is Ubuntu [01:27] yes I understand the difference [01:27] so it doesn't sound like you have any problems [01:27] I don't. I'm trying to figure out how it's working exactly. [01:27] its like using NoCloud Ds with libvirt providing a cidata ISO [01:28] what does the D mean in what you just typed [01:29] DS = DataSource [01:29] okay, I thought you mean Ds and in plural D [01:29] meant* [01:29] did you try searching online? one of the 1st links I found explains how libvirt works with cloud-init [01:32] and assuming you're using this, https://registry.terraform.io/providers/DevScrewOps/libvirt/latest/docs/resources/cloudinit with Terraform its description mentions it creates a cidata ISO [01:35] but none of this relates to what you were initially talking about [01:36] I'm using this provider: https://github.com/dmacvicar/terraform-provider-libvirt . Let's go back to the original confusion regarding network configuration. See here: https://github.com/dmacvicar/terraform-provider-libvirt/blob/main/examples/v0.13/ubuntu/network_config.cfg I just copied this on faith and it works. Which is fine, but I want to understand why. Is 'ens3' baked into the image? How [01:36] can I check that myself? [01:36] ens is a network interface, the naming of which depends on the distro you are using [01:37] that's nothing specific to cloud-init [01:37] yes I know [01:37] I think I know where I'm not being clear, sorry. [01:37] one sec [01:39] So let's say I roll my own image. Do I bake-in the network interface and put in documentation "use this interface in your cloud-init configurations" or do I leave it up to cloud-init (the documentation for which suggests some link detection magic) or do I do something else? I'm thinking from kind of a managerial perspective, sorry for being unclear earlier. [01:40] no you don't "bake in" the network interface, when any machine boots it will "see" whatever network interfaces are present, again that's nothing specific to cloud-init [01:40] how such network interfaces are named is down ot the particular distro/OS config you are using [01:41] i.e. old style "eth0, eth0" versus newer style scheme [01:41] s/eth0, eth0/eth0, eth1/ [01:43] also are you asked specifically about "local" VM hypervisor environments only, not including Cloud Providers? [01:44] yeah I know there's old style vs predictable naming scheme new style. In the example above, how is it guaranteed that ens3 is always going to be there on that xenial image? [01:44] a interface isn't "on" a OS image, it is on a physical/virtual machine that happens to be running the OS image [01:45] let me rephrase [01:45] can you answer my last last question please [01:45] I have no questions about cloud providers specifically no. [01:45] ok, as network config doesn't apply there [01:46] so have a look at the docs regarding the network-config file: https://cloudinit.readthedocs.io/en/latest/reference/network-config.html [01:46] specifically the links to the NoCloud v1 and v2 file formats [01:48] with NoCloud I have my OS configured to use old style names so the 1st (perhaps only) network interface is eth0 [01:48] I see. Thank you! this helps [01:49] I should've kept reading this page before asking here. [01:49] so there's no match keys in the network interfaces I'm using, which makes it seem like magic. So I'm assuming there is something in the xenial image forcing ens3 onto a deteced network interface. [01:50] s/interfaces/configuration/g [01:51] or perhaps it is using the "fallback" of DHCP on the 1st present interface [01:51] I think that's what's happening because no amount of grep'ing or find'ing is turning up the interface configuration on the VM post-boot. [01:52] eh? cloud-init will be setting the config appropriately [01:52] as it's Ubuntu it should be setting the netplan config file [01:52] disregard, nevermind haha [01:53] anyway, thanks for you time. I should focus on this NoCloud type of config. [01:53] s/you/your lol [01:53] cloud-init "renders" any network to the appropriate form for the distro (/etc/network/interfaces, netplan, sysconfig, etc) [01:53] yeah, I realized the mistake of my last message wrt to that [01:54] well you said you're not using Cloud Providers so yes, only NoCloud, is appropriate [01:54] if you enable debugging for the cloud-init logfile you'd see what exactly it is doing [01:54] thanks, I'll try that out [10:47] oops https://github.com/NetworkConfiguration/dhcpcd/issues/195 [10:47] -ubottu:#cloud-init- Issue 195 in NetworkConfiguration/dhcpcd "dhcpcd bypasses firewall" [Open] [15:42] @eb3095-Vultr: I have a question for you regarding __main__ in DataSourceVultr.py if you get a chance. See -> https://github.com/canonical/cloud-init/pull/2122/files#r1166094268 [15:47] holmanb: just starting to look at your dhcp changes [15:48] I guess fixing the dhcp stuff in NoCloud (for seed url access) would come via a different PR [15:57] holmanb: any [15:57] … [15:58] do you want me to do a pr with the FreeBSD changes now, against your pr, or after it lands? [15:59] meena: after - just wanted your awareness for now [16:00] aye [16:01] minimal: what needs to get fixed in nocloud for seed url? [16:01] minimal: not sure I follow [16:03] holmanb: I mentioned previously that it is using the "fallback" method of adding an entry in /e/n/i and the relying on OS to bring up interface so that c-i can then fetch URLs to then read network config from meta-data to then rewrite /e/n/i [16:03] ahhh right that part [16:03] but the 2nd (proper) network config is never activated as the interface is already up [16:03] basically NoCloud in general uses fallback in no CIDATA found, which is fine [16:04] however for seed URL use fallback IMHO should *NOT* be used [16:04] rather the interface should be upped and dhcp client run, and then after URLs fetched it [16:04] addr should be deleted [16:05] Yep, I remember now. I'd like that issue to be a separate PR. [16:05] It probably deserves a LP bug. [16:06] ok, guess I'll raise an LP bug then, I don't currently understand the relevant parts of the code to write a PR yet [16:07] appreciated, thanks [16:07] BTW with your current WIP I guess the idea of doing DHCP all in python is no longer being considered [16:10] it's certainly still possible (easier, even with the refactor), but not the current plan [16:11] ok [16:14] There was some internal hesitation around that approach with maintaining a custom client for only cloud-init, and dhcpcd is required anyways in images for initramfs, so the dhcpcd approach is seen as lowest risk/difficulty and doesn't require maintaining / adding new dependencies that aren't already needed in base images. [16:16] Like I said, that could certainly change, and this PR doesn't lock us into that approach. [16:17] Also I see someone just offered a proposal for udhcpc [16:47] I got that going to look when I get home in a few [16:53] holmanb: udhcpc "suffers" from the same limitation as dhclient, 1 process cannot do both IPv4 and IPv6 [16:55] but yes it is good to see udhcpc interest, I'm interested in it as it is the default dhcp client for Alpine [16:58] honestly, can't wait for dhcpcd in FreeBSD [18:56] eb3095-Vultr: much appreciated, thanks [18:58] np! [22:20] What do you use to verify your cloud-init isn't typoed?