[01:07] I am looking for a way to ship some files (or rather just some shells scripts) with the cloud init. I can't seem to find a (straight forward) way of doing so. [01:07] Isn't that what "user-data scripts" should be? [01:11] or is there a way to reference a file for the content of a write_files in the cloud init? [01:37] maybe as context ... I am running this from terraform as .... user_data = file("cloud-config.yml") [01:40] is this what I am looking for? https://registry.terraform.io/providers/hashicorp/template/latest/docs/data-sources/cloudinit_config [01:52] or is there an easier way to upload a couple of files alongside of cloud init? === toolz is now known as Daniel === cpaelzer_ is now known as cpaelzer [10:12] Hi [10:13] Is there a way to define cloud-init user-data and network-data in the same file ? === rbasak_ is now known as rbasak === andrewbogott_ is now known as andrewbogott [13:56] godofsea: It would depend entirely on the datasource AFAIK since how network data is obtained is DS-specific. [14:17] right, network-data comes from the datasource, not the user-data [14:18] blackboxsw: release PR is up https://github.com/canonical/cloud-init/pull/993 [14:18] Pull 993 in canonical/cloud-init "Release 21.3" [Open] [15:26] akutz, falcojr yeah I have the datasource specific network-data config, I am trying to set it up on proxmox, for some reason the user-data config is applied but the network data is not applied. [16:18] falcojr: thanks reviewing daily integration test results now to make sure we aren't looking at degraded behavior etc. [16:56] meh, falcojr running tox -e integration-tests locally do you get SSH banner protocol errors from pycloudlib frequently? [16:57] I see it on CLOUD_INIT_OS_IMAGE=hirsute or focal [16:57] running tox -e integration-tests tests/integration_tests/modules/test_ssh_keysfile.py [17:06] PR is already up for the bottom one [17:06] I haven't seen banner errors though [17:25] godofsea: i just set 2 different settings for user-data and network-data: qm set "$vmid" --cicustom "user=local:snippets/cloud-init-$vmid-user.yaml,network=local:snippets/cloud-init-$vmid-network.yaml" [17:26] it did take me some time to get the syntax of the network.yaml right tho [17:29] Nothing4You, yeah I think that's the thing, my syntax is wrong I guess. I have to define route: ... [17:29] godofsea: this is how my network yaml looks like: https://paste.debian.net/plainh/c38c6325 [17:32] in my case i'm adding netplan to the image btw and using that to render [17:34] Nothing4You, this is mine https://paste.debian.net/1208728 , how are you adding netplan to the image ? [17:35] godofsea: https://paste.debian.net/hidden/fbee5058/ [17:35] haven't tested with bullseye yet but it works fine for me on debian buster [17:37] godofsea: i think you just need to remote the top most network object [17:37] and have everything go up one level [17:37] s/remote/remove/ [17:38] netplan shouldn't be needed for most things though, in my case i do need it specifically because otherwise i can't set routes with specific source ips i think [17:39] that makes sense, I had to create the netplan file manually using the console. It was a pain. This is why I am moving to cloud-init [17:39] I will try it without the topmost network object [17:40] this is the kind of stuff i'm playing with :) https://paste.debian.net/hidden/7d8aae64/ [17:41] (+ipv6 but stripped for simplicity) [17:41] ahh nice! similar to what I am trying to do :-) [17:42] XD [17:42] falcojr: thanks for the PR https://github.com/canonical/cloud-init/pull/992/files [17:42] Pull 992 in canonical/cloud-init "testing: Fix ssh keys integration test" [Open] [17:43] falcojr: merged https://github.com/canonical/cloud-init/pull/993 [17:43] Pull 993 in canonical/cloud-init "Release 21.3" [Merged] [17:44] Nothing4You, can you please explain what you are doing from line 34 in https://paste.debian.net/hidden/fbee5058/ [17:45] that's basically just the commands running in the chroot env [17:45] so on 37 i force netplan as renderer as it may otherwise not use netplan if other renderers are installed [17:46] line 46 enables mem hotplug as per https://pve.proxmox.com/wiki/Hotplug_(qemu_disk,nic,cpu,memory) [17:46] rest should be mostly self explaining [17:47] line 20 is because the debian cloud image has the partition numbers out of order [17:47] godofsea: does that answer it? [17:48] yeah, makes sense now :) Thanks [17:48] i also have a version that turns the image into btrfs [17:49] https://paste.debian.net/hidden/d1089069/ [17:49] woahh !! Cool [17:53] I haven't really worked with btrfs, What advantages does it have over ext4 ? Nothing4You [17:53] snapshots for starters [17:53] compression [17:54] you can also btrfs-send snapshots over the network for backups if you wanted [17:55] note though that with btrfs in the image i believe all vms from that image will share the volume uuids, so you may not want to use it this way if you intend to send snapshots between machines [17:56] i don't think that was something that could easily be reset e.g. by cloud-init [17:59] removing the topmost network object worked :) [18:00] nice [18:03] it worked, somewhat, still can't connect to internet. But that's a different issue. [18:04] i don't think you should have the scope link on the default route [18:08] Nothing4You, This has worked for me in the past, I add this https://paste.debian.net/hidden/14aa2375/ to netcfg.yaml file and then sudo netplan appy. it worked. [18:10] can you access the guest at all currently to verify the effective config? [18:10] as in only internet connectivity dead? [18:11] I can access it via console but not over the internet [18:11] what do you get from `ip r`? [18:12] considering that you have a /32 on the interface address i don't think it's able to set the gw route [18:12] unless that is automatically set with scope link? [18:12] not sure [18:12] also just reading your snippet again [18:12] host ip via 0.0.0.0/0 doesn't make sense [18:13] i read that the other way round [18:13] i'm not sure about the order of the routes, but if you first put the host route with scope link and then you put the default route (as explicit route instead of gateway4) then i think you should be good? [18:13] so when I do ip r , I get `default via .254` [18:14] and no route to the host ip? [18:14] i think you need routes 1 and 3 from my example (skipping from:) https://paste.debian.net/hidden/7d8aae64/ [18:14] yeah 2 lines of output, 2nd line is ` .254` [18:15] can you grab the full line? there's more info than that to read [18:16] default via GATEWAY dev ens18 proto static [18:16] GATEWAY dev ens18 proto static scope link [18:16] that's what mine looks like if i strip the 2nd route and the src ip part [18:16] scope link on the gw route and the other one just towards GATEWAY [18:17] default via .254 dev ens18 proto static [18:17] .254 dev ens18 proto static scope link [18:17] This is it [18:17] ok, looks the same as mine then [18:17] can you ping the host ip? [18:19] Host ip is the IP address of the proxmox machie [18:19] yes, can you ping the proxmox host from inside the vm? [18:19] okay [18:21] It says destination host unreachable [18:22] you tried to ping the ip that is in the link scoped route, right? [18:23] Yeah both, the one with .254 and the actual proxmox Host IP [18:24] did you configure the proxmox host to actually have .254 on the interface that is connected to the vm? [18:25] Interesting ! I reinstalled proxmox, and upgraded it to 7, so its clean, didnt do anything like that [18:26] got a link ? [18:26] well if you don't configure proxmox to have an interface with that ip it's not surprising you can't reach it [18:26] idk, i don't use any of proxmox's builtin network capabilities as they're not flexible enough for me [18:27] https://pve.proxmox.com/wiki/Network_Configuration can probably guide you through the process [18:28] found this https://pve.proxmox.com/wiki/OVH [18:28] > for Proxmox VE 4.x. [18:28] not sure how well that still applies [18:28] it also depends on how isolated you want to build your network, e.g. if you trust your vms to not steal each others ips you can put them all on the same bridge interface [18:28] if you don't trust your vms what i'm doing is having a bridge interface per vm [18:29] you also don't necessarily need a .254 ip [18:30] Yay, 21.3 is merged!!! [18:30] also depends on whether you have public ips for your vm and a couple other factors, most of my vms have a native ipv4 address routed to them [18:31] actually all my vms should be accessible via the internet so all of them have their own unique IP [18:32] then you could even get away without having a private ip range [18:33] just use the same host ip on all bridge interfaces (if you have multiple) and have the vms route to the host interface [18:33] *route to host ip [18:34] and on the host you need the route(s) to the bridge interface(s) [18:35] I think my bridge port is wrongly defined in /etc/network/interfaces [18:37] https://paste.debian.net/hidden/f4d4ffb6/ this is how it looks, bridge port is correct nvm [18:39] just to be sure, .254 is the ip of the provider gateway, right? [18:40] and your current goal is to have the proxmox host behave like a switch? [18:40] for the first question yes, [18:41] 2nd one is also yes , I guess [18:41] ok [18:42] my setups are normally that the host is a router instead of a switch so i was thinking about a slightly different setup [18:44] It's okay. I can come very far, I will figure it out from here on. Also can you gimme a link where I can read about these things, network stuff . subnets and other things like that. [18:45] i don't have any specific resources, what you're looking to set up is (for the host part) probably this https://pve.proxmox.com/wiki/Network_Configuration#_default_configuration_using_a_bridge [18:45] and it looks like you have that already [18:45] your provider may be limiting which macs can route traffic to it, so if your host acts as a switch the vm mac will be forwarded [18:46] the ovh proxmox page also mentions that: First you need to use the OVH manager to create a virtual mac address for the address you want to assign. Then you can create the virtual machine in the Proxmox VE GUI and assign the generated mac address to your virtual network card. [18:46] that might even be all that's needed to get it to work [18:46] assuming you're using ovh [18:47] ahh okay. [18:47] i have the same thing at hetzner but as i use the host as a router i don't need that [18:49] lemme look up the difference between router and switch real quick [18:58] Mine's a router not a switch :) [18:58] with bridge-ports eno1 it behaves as switch [19:00] it's also easier to set up that way === m_ueberall is now known as ueberall [19:04] I think its got something to do with OVH manager. Thanks Nothing4You for all the help. Signing off [19:04] np, good luck [20:10] I am telling everyone at work who will listen about this link -- https://cloudinit.readthedocs.io/en/stable/topics/datasources/vmware.html. Thank you for all your help blackboxsw, falcojr, minimal, rharper, and everyone else! [20:11] 🎉 [20:16] akutz: \o/ [21:22] falcojr: https://github.com/canonical/cloud-init/pull/992 can land if we rebase .... again. [21:22] Pull 992 in canonical/cloud-init "testing: Fix ssh keys integration test" [Open] [21:25] doh... [21:25] falcojr: also are you putting up a PR for the upload to impish? [21:25] probably after 992 lands? [21:26] yeah, I gotta get some food going first though :) [21:50] landed https://github.com/canonical/cloud-init/pull/992 [21:50] Pull 992 in canonical/cloud-init "testing: Fix ssh keys integration test" [Merged] [21:51] if a PR is put up for Impish upload, I'll review and dput it [21:58] blackboxsw: https://github.com/canonical/cloud-init/pull/994 [21:58] Pull 994 in canonical/cloud-init "Ubuntu/devel" [Open] [22:09] building will upload if all's good [22:16] falcojr: [ubuntu/impish-proposed] cloud-init 21.3-1-g6803368d-0ubuntu1 (Accepted) I'm merging now [22:17] https://github.com/canonical/cloud-init/pull/994#pullrequestreview-736612813 merged [22:17] Pull 994 in canonical/cloud-init "Ubuntu/devel" [Merged] [23:10] Sweet, I threw up the other branches too