[00:05] *nod* [13:07] Hello guys : ), I need help with a bit of a chicken and egg problem I got with net config with cloud-init: [13:07] I want to set up a fixed IP address for my VMs using cloud-init network config, I'm using a "NoCloud" net datasource, and my data is accessible at http://192.168.1.100:8080/config. The configuration files are located at: [13:07] - http://192.168.1.100:8080//user-data [13:07] - http://192.168.1.100:8080//network-config [13:07] The issue is that cloud-init needs to use DHCP to initially get an IP address before it can read the 'network-config' file, but I want it to read the data with the ip address I gave to it in 'network-config' file. Is there a way to do this? how do cloud providers like AWS or DigitalOcean configure the IP addresses of their machines? [13:07] Thanks in advance [13:21] aws uses dhcp [13:22] m-rahal: what kind of virtualization do you use? [13:22] oh yeah, I use libvirt [13:24] with qemu you can pass data to a VM with the smbios option too [13:26] or with the user-data in an iso image [13:26] I'm using libvirt XML instead to pass the datasourc option into simbios, i passed the url of the network datasource ds=nocloud;s=http://192.168.1.100:8080/config [13:26] this ISO image would work here, but I want to know if it's possible without it [13:28] Everything works (user password, ssh keys config ...) except for network config [14:26] m-rahal: does the following fit your use case? one can pass a base64 encoded yaml network config in the kernel command line using the network-config key: https://cloudinit.readthedocs.io/en/latest/reference/network-config.html#default-behaviour === arif-ali_ is now known as arif-ali [15:32] m-rahal: from my own previous testing of nocloud-net cloud-init does NOT fetch network-config via http/https, only metadata. user-data, and vendor-data [15:32] you can however embed (a limited form of) network config info in the metadata content [15:40] Hi! I'm experiencing some curious behavior I don't quite understand. I have a `virt-install` script that creates VMs based on a debian 12 cloud-init image. Previously, VMs created like this worked just fine, and used a default ENI network configuration. I just created another such VM where network wasn't working. In fact, neither `ifupdown` was installed, nor did the host get an IP. After manually adding the package via [15:40] cloud-init, it was present, and it got an IP, but not due to ifupdown running (config is now present but empty), but rather because apparently systemd-networkd was socket activated. I changed neither the cloud-init base image nor the configuration compared to previous installations. Why did the behavior change? [15:49] Schrostfutz: hello o/ [15:49] Schrostfutz: have you tried comparing the log files of these two images? [15:53] Schrostfutz: as for the change, I haven't checked for myself, but I heard that debian 12 moved to netplan for cloud images [15:53] Schrostfutz: https://blog.slyon.de/2023/07/10/netplan-and-systemd-networkd-on-debian-bookworm/ [15:55] holmanb_, Ah, that will probably be the reason. I'm still confused how this changed without me updating the base image. Does cloud-init do an automated update to itself in the setup process? [15:55] holmanb, Code_Bleu: haven't fixed the commit message yet, and the python side is still missing, but here's a better fix for the /run issue: https://github.com/canonical/cloud-init/pull/4677 [15:55] -ubottu:#cloud-init- Pull 4677 in canonical/cloud-init "hack(sysvinit): On *BSD, create /run as symlink" [Open] [15:56] aaaaaaand unittests are failing [15:56] but first: laundry [15:56] holmanb_: I'm looking into the logs but can't really find anything. The output of the cloud-init.service is quite short and looks comparable. In particular the versions match (22.4.2) [16:20] Schrostfutz: you want to be looking at /var/log/cloud-init.log [16:20] Schrostfutz: cloud-init has 4 services [16:20] Schrostfutz: and much more information ends up in the log than in the journal from that service [16:23] holmanb_: Ah, I see! I'll have a look at that [16:26] Schrostfutz: Look for tracebacks and ERROR/WARN messages first [16:26] Anythin that looks abnormal [16:27] holmanb_: No traces or errors. Everything seems plausible and save for minor differences in order, temporary names or filesizes die to changed parameterization they are identical... [16:30] Just in case this is of interest to you, the old and new installation logs (http://sprunge.us/gnJjdX, http://sprunge.us/k5wWjF). I just pruned out the time prefixes to make them diffable. The old installation is from 20.09, the new one from 13.12. [16:30] check for references to the network renderer used in both situations ("eni", "netplan", etc) [16:31] meena: I like the general approach in the PR [16:31] meena: good call preserving env variable override backwards compability [17:21] holmanb_: now to spend four hours finding out why the tests are falling [17:22] meena: :/ [17:23] one of these days, I'll get really good at it. probably when we rewrite cloud-init to Ruby [17:42] meena: lol [17:43] most of the ruby I've ever written was vagrant VM launchers [17:45] I wrote a vagrant launcher that could set up multiple VMs on a network with ethernet and IB virtual devices connecting the cluster for testing a custom routing protocol based on ospf (that we wrote) [17:45] that was my most complex ruby thing [17:46] but it wasn't open source :.( [17:47] and I basically just reinvented a much crappier version of GNS3 [17:51] Schrostfutz: making any progress? [17:53] holmanb_: Not really... I can't spot it. But I'm also considering just accepting that since the new approach now works as well [18:17] como funciona o cloud-init [18:21] ira: Fala inglês ou alemão? [18:22] Schrostfutz: I think I missed that, what's the new approach [18:22] eu falo só português do brasil [18:24] holmanb_: do we have translated documentation? [18:25] doesn't look like it [18:27] no translations that I'm aware of [18:29] ira: este tutorial ensina como funciona o cloud-init [18:29] ira: O cloud-init é pré-instalado em uma imagem de VM. Em seguida, ele é inicializado em uma nuvem e faz toda a personalização necessária para começar a trabalhar nessa nuvem específica. Depois carrega os dados do utilizador e faz mais personalizações. [18:29] ira: https://cloudinit.readthedocs.io/en/latest/tutorial/qemu.html [18:30] ira: está apenas em inglês, infelizmente [18:31] obrigado [18:38] Preciso aprender mais idiomas. [18:46] e eu o de vocês hehehe [18:50] next up, French: https://languagehat.com/how-africans-are-changing-french/ [19:21] meena: since you're the BSD expert...and I'm still waiting for a reply in #openbsd...I was wondering if you knew of a way to scan for hardware changes? I added a HD to a VM ( virtio ) and was wondering if I could detect it without rebooting? Sorry for the not cloud-init related question. [19:22] Code_Bleu: if it doesn't show up in dmesg, then yes, you need to reboot [19:23] meena: it doesn't, but was just wondering if there might be some other app or setting I just didn't have set to allow this to happen? [19:25] device initialization in OpenBSD only happens at startup [19:28] hey hey - what's the *right* way for populating LANGUAGE in locales? [19:37] ed_: hey [19:42] ed_: which distro? [20:05] holmanb: well not approach, rather the new behavior that I've noticed. That being netplan configuring the network [20:11] meena: ubuntu, late commands seems to get overwritten [20:45] ed_: late commands? what are those? [20:49] holmanb_: https://ubuntu.com/server/docs/install/autoinstall-reference [20:53] ed_: ah, that's autoinstall not cloud-init [21:05] ed_: for autoinstall questions on irc, #ubuntu-server is your best bet [21:23] holmanb_: thanks - i got documentation blinded... not the first time :) [21:31] meena: regarding your crimes -> not pretty, but I assume it works? alternatively if we use a different command that has stderr output and a non-zero exit code that's more compatible across unix and linux that would work too [21:31] ed_: no problem, best of luck [21:32] holmanb_: yeah, i think that's probably a better idea [21:33] holmanb_: `cat /non-existent` looked promising, but looks different with busybox [21:33] meena: something like this maybe? [21:34] sh -c 'echo test 1>&2; exit 42' [21:34] meena: yeah, figure that posix shell should do the right thing everywhere [21:34] that shit better work, or something's really broken. [21:34] * meena boots up openbsd [21:35] holmanb_: yeah. looks good. [21:36] meena: nice :) [21:36] want me to submit that, cuz I reckon you're a bit busy with 103230494 (rough estimate) other things [21:38] meena: if you don't mind [21:38] thanks [21:38] heh [21:40] need to rerun tests cuz I forgot which one was failing lol [21:56] holmanb_: https://github.com/canonical/cloud-init/pull/4692 [21:56] -ubottu:#cloud-init- Pull 4692 in canonical/cloud-init "fix(tests): make cmd/devel/tests work on non-GNU" [Open] [22:16] meena, nice thanks [22:16] now to get back to figuring out why my other tests are failing [22:16] my ds-identify tests [22:19] merged 4692 [22:36] python needs Ruby's pry and pry-debug [23:38] aaah, grrrrrrrr found the issue [23:39] cfg_out = os.path.join(rootd, "run/cloud-init/cloud.cfg") [23:39] that file doesn't exist. [23:39] it should be using… something else. [23:39] get_runpath? [23:40] anyway, too tired to fix this now. But I'm glad I've identified it. [23:42] i think ds-identify is now in its final state, and it's just the tests that need fixing.