[10:46] <meena> cjp256: I'm working on fixing get_interfaces() and get_interfaces_by_mac() for FreeBSD, and if I understand you correctly, we don't need the blacklist drivers hacks for BSD
[11:12] <meena> currently using defaultdict from collections, like holmanb recommended. Not sure it's the way to go…
[13:30] <holmanb> meena: I'm always looking for improvements :)
[13:30] <holmanb> Have something else in mind?
[13:31]  * holmanb tries to remember the context of what he suggested
[13:37] <cjp256> meena: correct, we wouldn't need blacklist_drivers blasted everywhere, but would we need get_interfaces() to provide driver name, and I'd suggest deprecating/removing _by_mac() variants where possible to avoid duplicate mac problems in the issue
[13:38] <cjp256> future*
[13:38] <meena> holmanb, cjp256 https://github.com/canonical/cloud-init/compare/main...igalic:cloud-init:bsd/fix_duplicate_macs?expand=1
[13:45] <meena> if MAC addresses aren't unique, are names? 
[13:46] <holmanb> I remember a conversation related to this topic. Still not remembering the specifics related to this, however 
[13:46] <holmanb> Shower/food now, will reload memories from irc after and get back to you
[13:48] <klnikita> hello there, I'm a network guys from scaleway. caribou told me that they were some questions regarding our network setup, the /32 with the on link gw. If the topic is still open and you have some questions feel free to ask :)
[13:56] <meena> klnikita: We, or rather, holmanb, have now discovered other cloud providers who have the same sort of setup 
[14:01] <klnikita> yeah, having the /32 used as the primary IP of a VM may seems unusual but it facilitate many things regarding VM live migration, network underlay setup and some other subtilities
[14:02] <cjp256> holmanb: fwiu blacklist_drivers is only used for Azure to prevent cloudinit from trying to configure the mlx[45]  interfaces.   This list is set by the Azure datasource and it later gets reset when the distro object is cleared, so it's not working everywhere as intended.  (see PR #1853 workaround).  And the assumption that all interfaces have unique macs is not 100% correct which is leading to bugs in _by_mac() usage.  FreeBSD does not 
[14:02] <cjp256> currently work at all with the mlx/mce interfaces because there is no queried driver name to account for and alphabetically the mce0 interface is taking precedence over hn0 when it builds the dictionary by mac.  We need a cross-platform way of get the interface list with driver name (see PR #1672).
[14:06] <meena> cjp256: i'm really confused by the fact that the current implementation of get_interfaces() doesn't return anything… here's my development version: https://gist.github.com/1beba16360db0d9eb6e60aa29739adfe
[14:09] <meena> cjp256: btw, as you can see, on BSD, the output is *not* alphabetic… the order is already as indexed by the kernel
[14:10] <cjp256> meena: i think net.get_interfaces() is very Linux-specific and unused in the bsd paths?
[14:11] <meena> cjp256: net.get_interfaces() dispatches to other functions. The plan (https://github.com/canonical/cloud-init/blob/main/WIP-ONGOING-REFACTORIZATION.rst ) is to move those functions from net into distro.
[14:12] <cjp256> meena: can you plumb in the text from https://github.com/canonical/cloud-init/pull/1672#discussion_r1047795909 and see what would happen?
[14:12] -ubottu:#cloud-init- Pull 1672 in canonical/cloud-init "sources/azure: fix device driver matching for net config" [Closed]
[14:15] <meena> cjp256: https://gist.github.com/4e3c2d8fbb1a6aac7e16f1caf99b605e
[14:17] <cjp256> awesome, thanks :D
[14:18] <meena> I wonder what the output of __repr__() on Ifstate could look like to make it useful…
[14:18] <cjp256> so if we're trying to apply the equivalent of blacklist_drivers on top of this, is there a way to query for the driver name of an interface? or would we end up relying on the device naming scheme? that is mlx* vs. mce*?
[14:19] <meena> cjp256: netbsd and openbsd: Yes. FreeBSD… ooooooooof: https://github.com/canonical/cloud-init/compare/main...igalic:cloud-init:bsd/device_drivers
[14:20] <meena> FreeBSD allows renaming nics but gives us no easy way to get back at the original name…
[14:22] <cjp256> so in my example above, that would return "mce" as the driver name?
[14:23] <meena> cjp256: yes
[14:23] <meena> i probably could also get a table to normalize the names
[14:24] <meena> every driver in BSD is documented
[14:25] <meena> https://man.freebsd.org/mce(4) is mlx5en
[14:31] <cjp256> I think that'd be fine if the mapping is well understood.  I don't see the name for mlx4 in the docs so I'm gonna spin up a VM and see what it is out of curiosity
[14:32] <meena> confusingly,  https://man.freebsd.org/mlx(4) is something different. Mylex DAC-family RAID driver
[14:34] <cjp256> https://man.bsd.lv/FreeBSD-13.0/man4/mlx4en.4 :D
[14:36] <meena> cjp256: that's so much nicer rendered… when will FreeBSD adopt that??
[14:36] <cjp256> https://www.irccloud.com/pastebin/n8R734Uq/
[14:36] <meena> when will someone at FreeBSD have some time to migrate to that thing
[14:36] <meena> mandoc
[14:37] <cjp256> looks like it came up as mlxen*
[14:38] <meena> cjp256: the mce(4) man page tells you exactly what the nic will come up with as
[14:39] <cjp256> yeah that was nice
[15:06] <minimal> klnikita: I guess we were surprised by the /32 PtP use of the interface. Your metadata server is providing a version1 network-config right? I was wondering how it flags the interface as PtP using that
[16:03] <caribou> minimal: that's my upcoming tasks : make sure that the mods work for all rendering otherwise I'll need another solution
[16:06] <minimal> I've noticed a couple of other providers using /32 addresses in some situation, however for example OVH Bare Metal Cloud are using Openstack ConfigDrive to provide the network config (which is not v1 or v2 format, it's JSON), and Hetzner I'm not sure if they use cloud-init at all for the situations where they provide static /32 (i.e. maybe its only for bare metal, not sure)
[16:33] <meena> minimal: hetzner solves this by using DHCP… or at least falling back to DHCP
[16:35] <meena> it was only when I decided i need 1 less daemon running, that i was trying to figure out how to get that peer-to-peer config configured on FreeBSD… like, they don't even document it for FreeBSD: https://docs.hetzner.com/cloud/servers/static-configuration — i had to figure it out on my own:
[16:35] <meena> https://gist.github.com/igalic/642efb4e0f4da255382bc299ec65ce83
[16:53] <minimal> meena: with DHCP is the default route handled ok?
=== janitha70 is now known as janitha7
[17:23] <meena> minimal: yupp
[17:26] <meena> minimal: i don't know if Hetzner uses cloud-init for hardware
[17:54] <klnikita> the correct term for this kind of connectivity is "directly connected gateway", pointopoint is something different
[17:57] <minimal> ok, I meant that its effectively using ethernet as a non-broadcast network, which is typically what "pointopoint" signifies, sort of like an unnumbered PPP link
[17:57] <meena> klnikita: you tell that the Debian folks. i think they're the ones who started it
[17:59] <klnikita> yep sorry, I didnt saw that my irc was not on the last message actually, I was thinking that last chan msg was still about adding it in ifupdown :)
[17:59] <meena> cjp256: passing this on: 	<CrtxReavr> I don't have either of those devices.  Maybe you could share the output of 'grep mlx /var/run/dmesg.boot'
[18:04] <klnikita> if I'm not mistaken it should work pretty out of the box with ifupdown https://salsa.debian.org/debian/ifupdown/-/blob/master/inet.defn#L43 but I have not tested it 
[18:05] <klnikita> and, it wont work on ifupdown + kfreebsd
[18:07] <minimal> and probably not with ifupdown-ng on Alpine
[18:18] <klnikita> yep it won't work, https://github.com/ifupdown-ng/ifupdown-ng/blob/main/executor-scripts/linux/static#L36 is missing the "onlink" option at the end 
[18:19] <minimal> I think the situation is (a) where addresses and routes are allocated via DHCP then its down to the particular DHCP client as to what happens, or (b) where the provider's metadata server or ConfigDrive/NoCloud files provide network config via non-DHCP then (b1) how does the provided v1/v2 network config indicate a "onlink" route to cloud-init, and (b2) what then does cloud-init put into each of sysconfig/eni/etc files to signify such an "onlink" route 
[18:19] <minimal> such that the OS'es handler for their own distro-specific config file know to deal appropriately with it
[18:20] <minimal> klnikita: yupe, had just checked that myself - I think adding "onlink" to the "ip route add default" statement would be "bad" as "onlink" should only be used when specified/required
[18:22] <klnikita> yep agreed, without the onlink you got an "Error: Nexthop has invalid gateway." error which protect about most misconfiguration
[18:23] <klnikita> I guess the onlink just disable the check
[21:31] <esv> hello folks, scripts located in the per-instance section or subdirectories should be executed only once upon machine creation, right?
[21:43] <ananke> esv: or when said OS is booted on another instance (which varies with actual implementation). but yes
[22:42] <holmanb> meena: forgot to circle back to you this morning, sorry about that
[22:43] <holmanb> meena: I think it was aciba who was talking to you about using defaultdict (explains my brain-gap)
[22:43] <meena> holmanb: ah,
[22:43] <holmanb> meena: https://irclogs.ubuntu.com/2022/11/16/%23cloud-init.txt
[22:43] <meena> i'll test with defaultdict and see where it goes
[22:43] <holmanb> sounds good
[22:46] <meena> i need to figure out how to access stuff in it first.
[22:47] <meena> actually, maybe a list of tuples might be better, tho not much easier for easy access either…
[22:47] <meena> names are unique, always, right?
[22:48] <holmanb> "always" begets more research before giving a confident answer
[22:49] <holmanb> I'll say: I've seen multiple instances of systems with duplicate macs, multiple different setups and scenarios. I don't _think_ I've ever seen a system with duplicate interface names.
[22:50]  * holmanb starts wondering about linux namespaces now
[22:53] <holmanb> my gut feeling is that multiple interfaces could be named the same (after an interface rename) in different network namespaces, but I'd have to dig a bit to confirm that and I haven't touched linux namespaces in a couple of years
[22:53] <holmanb> klnikita: hello and welcome :)
[22:57] <holmanb> klnikita: thanks for dropping by, catching up on conversation now - I'll possibly have a question or three for you once I do
[23:23] <cjp256> meena: not sure whatcha looking for, but here a dmesg for both mlx4 and mlx5
[23:23] <cjp256> https://www.irccloud.com/pastebin/MXHlSwZg/
[23:24] <holmanb> cjp256: ack, thanks for the refresh / context - will you reopen 1672 in a new PR? It doesn't look like we have the power to do that for whatever reason.
[23:26] <cjp256> holmanb: np, I'll reopen it, thanks!
[23:28] <cjp256> https://github.com/canonical/cloud-init/pull/1914
[23:28] -ubottu:#cloud-init- Pull 1914 in canonical/cloud-init "sources/azure: fix device driver matching for net config" [Open]
[23:28] <holmanb> cjp256: Nice, thanks!
[23:28] <holmanb> caribou: "make sure that the mods work for all rendering" -> By this do you mean that you're interested in contributing to cloud-init to help with support on this?
[23:34] <holmanb> rather - regardless of whether that's what you meant, is that something you're interested in doing?