[00:05] <meena> *nod*
[13:07] <m-rahal> Hello guys : ), I need help with a bit of a chicken and egg problem I got with net config with cloud-init:
[13:07] <m-rahal> 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] <m-rahal> - http://192.168.1.100:8080/<vm_name>/user-data
[13:07] <m-rahal> - http://192.168.1.100:8080/<vm_name>/network-config
[13:07] <m-rahal> 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] <m-rahal> Thanks in advance
[13:21] <gdamjan> aws uses dhcp
[13:22] <gdamjan> m-rahal: what kind of virtualization do you use?
[13:22] <m-rahal> oh yeah, I use libvirt
[13:24] <gdamjan> with qemu you can pass data to a VM with the smbios option too
[13:26] <gdamjan> or with the user-data in an iso image
[13:26] <m-rahal> 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] <m-rahal> this ISO image would work here, but I want to know if it's possible without it
[13:28] <m-rahal> Everything works (user password, ssh keys config ...) except for network config
[14:26] <aciba> 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
[15:32] <minimal> 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] <minimal> you can however embed (a limited form of) network config info in the metadata content
[15:40] <Schrostfutz> 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] <Schrostfutz> 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] <holmanb_> Schrostfutz: hello o/
[15:49] <holmanb_> Schrostfutz: have you tried comparing the log files of these two images?
[15:53] <holmanb_> 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] <holmanb_> Schrostfutz: https://blog.slyon.de/2023/07/10/netplan-and-systemd-networkd-on-debian-bookworm/
[15:55] <Schrostfutz> 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] <meena> 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] <meena> aaaaaaand unittests are failing
[15:56] <meena> but first: laundry
[15:56] <Schrostfutz> 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] <holmanb_> Schrostfutz: you want to be looking at /var/log/cloud-init.log
[16:20] <holmanb_> Schrostfutz: cloud-init has 4 services
[16:20] <holmanb_> Schrostfutz: and much more information ends up in the log than in the journal from that service
[16:23] <Schrostfutz> holmanb_: Ah, I see! I'll have a look at that
[16:26] <holmanb_> Schrostfutz: Look for tracebacks and ERROR/WARN messages first
[16:26] <holmanb_> Anythin that looks abnormal
[16:27] <Schrostfutz> 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] <Schrostfutz> 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] <minimal> check for references to the network renderer used in both situations ("eni", "netplan", etc)
[16:31] <holmanb_> meena: I like the general approach in the PR
[16:31] <holmanb_> meena: good call preserving env variable override backwards compability
[17:21] <meena> holmanb_: now to spend four hours finding out why the tests are falling
[17:22] <holmanb_> meena: :/
[17:23] <meena> one of these days, I'll get really good at it. probably when we rewrite cloud-init to Ruby
[17:42] <holmanb_> meena: lol
[17:43] <holmanb_> most of the ruby I've ever written was vagrant VM launchers
[17:45] <holmanb_> 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] <holmanb_> that was my most complex ruby thing
[17:46] <holmanb_> but it wasn't open source :.(
[17:47] <holmanb_> and I basically just reinvented a much crappier version of GNS3
[17:51] <holmanb_> Schrostfutz: making any progress? 
[17:53] <Schrostfutz> 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] <ira> como funciona o cloud-init
[18:21] <meena> ira: Fala inglês ou alemão?
[18:22] <holmanb_> Schrostfutz: I think I missed that, what's the new approach
[18:22] <ira> eu falo só português do brasil
[18:24] <meena> holmanb_: do we have translated documentation?
[18:25] <meena> doesn't look like it
[18:27] <holmanb_> no translations that I'm aware of
[18:29] <holmanb_> ira: este tutorial ensina como funciona o cloud-init
[18:29] <meena> 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] <holmanb_> ira: https://cloudinit.readthedocs.io/en/latest/tutorial/qemu.html
[18:30] <holmanb_> ira: está apenas em inglês, infelizmente
[18:31] <ira> obrigado
[18:38] <meena> Preciso aprender mais idiomas.
[18:46] <ira> e eu o de vocês hehehe
[18:50] <meena> next up, French: https://languagehat.com/how-africans-are-changing-french/
[19:21] <Code_Bleu> 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] <meena> Code_Bleu: if it doesn't show up in dmesg, then yes, you need to reboot
[19:23] <Code_Bleu> 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] <meena> device initialization in OpenBSD only happens at startup
[19:28] <ed_> hey hey - what's the *right* way for populating LANGUAGE in locales?
[19:37] <meena> ed_: hey
[19:42] <meena> ed_: which distro?
[20:05] <Schrostfutz_> holmanb: well not approach, rather the new behavior that I've noticed. That being netplan configuring the network
[20:11] <ed_> meena: ubuntu, late commands seems to get overwritten
[20:45] <holmanb_> ed_: late commands? what are those?
[20:49] <ed_> holmanb_: https://ubuntu.com/server/docs/install/autoinstall-reference
[20:53] <holmanb_> ed_: ah, that's autoinstall not cloud-init
[21:05] <holmanb_> ed_: for autoinstall questions on irc, #ubuntu-server is your best bet
[21:23] <ed_> holmanb_: thanks - i got documentation blinded... not the first time :)
[21:31] <holmanb_> 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] <holmanb_> ed_: no problem, best of luck
[21:32] <meena> holmanb_: yeah, i think that's probably a better idea
[21:33] <meena> holmanb_: `cat /non-existent` looked promising, but looks different with busybox
[21:33] <holmanb_> meena: something like this maybe?
[21:34] <holmanb_> sh -c 'echo test 1>&2; exit 42'
[21:34] <holmanb_> meena: yeah, figure that posix shell should do the right thing everywhere
[21:34] <meena> that shit better work, or something's really broken.
[21:34]  * meena boots up openbsd
[21:35] <meena> holmanb_: yeah. looks good.
[21:36] <holmanb_> meena: nice :)
[21:36] <meena> want me to submit that, cuz I reckon you're a bit busy with 103230494 (rough estimate) other things 
[21:38] <holmanb_> meena: if you don't mind
[21:38] <holmanb_> thanks
[21:38] <holmanb_> heh
[21:40] <meena> need to rerun tests cuz I forgot which one was failing lol
[21:56] <meena> 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] <holmanb> meena, nice thanks
[22:16] <meena> now to get back to figuring out why my other tests are failing
[22:16] <meena> my ds-identify tests
[22:19] <holmanb> merged 4692
[22:36] <meena> python needs Ruby's pry and pry-debug
[23:38] <meena> aaah, grrrrrrrr  found the issue
[23:39] <meena> cfg_out = os.path.join(rootd, "run/cloud-init/cloud.cfg")
[23:39] <meena> that file doesn't exist.
[23:39] <meena> it should be using… something else.
[23:39] <meena> get_runpath?
[23:40] <meena> anyway, too tired to fix this now. But I'm glad I've identified it.
[23:42] <meena> i think ds-identify is now in its final state, and it's just the tests that need fixing.