/srv/irclogs.ubuntu.com/2023/04/11/#cloud-init.txt

holmanbminimal: ahh interesting02:34
holmanbI saw something else today that had a bash shebang line that made me wonder if it was a hard requirement 02:34
holmanbSince POSIX shell is more portable that probably makes more sense anyway02:39
holmanbI'd have to dig a little to know what our hotplug testing looks like - I haven't touched that02:40
=== cpaelzer_ is now known as cpaelzer
minimalany particular reason why the NoCloud seed-from functionality doesn't fetch a network-config URL? After all eni network config can be embedded in the meta-data requested so why not support network-config also?15:41
gjollyHello cloud-init people! I was looking at boot times on Azure and especially for minimal Ubuntu instances (so without snapd running). Most of the boot time is spent on cloud-init-local.service (13s over 18s to reach ssh.service) and I would like to kindly ask you if you could have a look at those logs: https://pastebin.ubuntu.com/p/vCG8ztgJjd/ to see if there is anything that could be optimized there. Thanks!16:23
gjollyThe "Timeout too large reducing to: 2147483646 (TIME_MAX - 1)" made me wonder if something could be optimized here.16:25
blackboxswgjolly hi. looking that over, the timeout too large is actually the dhclient saying that the timeout Azure DHCP servers are sending us to too large, so dropping it locally to one less than the TIME_MAX. cloud-init in local boot stage on Azure relies on the DHCP backplane to give enough routing information for cloud-init to 'find' the instance metadata service on Azure in order to crawl it and collect desired network config for the vm.16:30
blackboxswgjolly: and as your logs capture given the time stamps, near the entirety of this boot time cost in init-local looks to be the dhclient request waiting on a DHCP response from Azure DHCP servers on this region. We could opt to set a tighter dhclient timeout if we don't like waiting 12 seconds..... but that will trigger cloud-init to give up on detecting Azure in init-local stage and fallback to "init network" boot stage.16:32
blackboxswit feels a bit like this DHCP server is overloaded possibly and not responding in a timely manner to DHCP requests.16:33
gjollyblackboxsw: Very interesting thank you for you help. I will try in other locations to see if it helps!16:35
blackboxswgjolly: please do, that is an incredibly long time to wait on init-local on Azure for DHCP response16:37
gjollyblackboxsw: cloud-init-local.service @673ms +4.243s indeed it's way better in this other DC.16:38
blackboxswthx, typical times we've seen for init-local are below 2 seconds generally16:41
meenaInfiniband is my arch nemesis.17:24
holmanbminimal: Not sure why it doesn't - I would assume historical reasons.20:04
holmanbas in, never got around to it or had a request for it20:04
holmanbSounds like a reasonable addition to me (and a better interface too).20:04
holmanbWe may want to deprecate the eni-specific key from meta-data too if we do add support for network-config at a url.20:06
minimalyeah, this area needs some work, I need to find some time to get back to testing it some more. I think it should be using ephimeral DHCP rather than configuring a network interface (via eni on Alpine/Debian) as that messes things up later (as the interface never has "ifdown eth0" performed and then the 2nd "ifup eth0" (with the IP settings passed via meta-info's eni-settings) fails20:12
holmanbthat sounds like a bug to me20:13
minimalusing "-f" for the ifup command acts as a workaround for ifupdown but doesn't work for ifupdown-ng20:14
holmanbgotcha20:16
holmanbmeena: stuck on something?20:16
minimalyeah it shouldn't we writing an /e/n/i file in the first place for its temporary interface config20:17
minimallooking at my old notes on this, its doing "Apply network configuration from fallback", then "Writing to /etc/network/interfaces"20:20
minimalin "init-local"20:20
minimalthen the os bring up the interfaces as defined in /e/n/i20:22
minimalthen c-i in "init" downloads from the seed-urls (include meta-data with the network settings)20:22
minimalthen it does "applying net config names for...." and "Applying network configuration", and "Writing to /etc/network/interfaces" (where this is the config obtained from meta-info)20:23
minimalthen then "Bringing up newly configured network interfaces" (which is already up as the OS did so between "init-local" and "init" stages)20:24
meenaholmanb: i got access to an HPC Azure machine with infiniband devices, and I have no idea how to even make it show it up in ifconfig as NIC20:32
minimalmeena: you have the hyper-v drivers active?20:37
meenaminimal: hn0 is up and running; 20:38
minimalso ifconfig hn0 shows nothing?20:43
meenaminimal: ifconfig hn0 shows the default config, otherwise i wouldn't be able to connect20:49
holmanbthis is using freebsd I assume?20:50
minimalso you should be seeing 2 interfaces per "virtual NIC" apparently, one via the hyper-v netvsc (which I assume is hn0 in your case) and the 2nd is a SR-IOV Virtual Function which shows up as a PCI device and uses the mlx driver20:57
minimalat least according to this: https://learn.microsoft.com/en-us/azure/virtual-network/accelerated-networking-how-it-works20:57
meenaminimal: that's on the more or less regular instances. This is an HPC instance, and the mlx nic is an infiniband device.23:11
minimalmeena: ok, seems like Mellanox OFED drivers may be required23:31
meenaminimal: they are loaded; the stuff shows up in pciconf, and in ibstats, and so on, but not in infconfig;23:32
meenaI am finding that somewhat confusing23:32
meenaI'm currently building FreeBSD 14.0-CURRENT, WITH_OFED_EXTRA to see if that gets me even a cm further.23:33
minimalthe documentation links I found on Nvidia's site for FreeBSD OFED don't work23:33
meenaLove me a good acquisition…23:34

Generated by irclog2html.py 2.7 by Marius Gedminas - find it at mg.pov.lt!