| 30 Jun 2025 |
 emily | in favour of NM or direct use of systemd.network.* | 15:07:18 |
| emily | rather than maintaining our own abstraction layers | 15:07:24 |
| emily | OTOH I think that means there's nothing preventing maintenance of an identical not-networking.* interface out of tree? | 15:07:42 |
 Molly Miller | true, that's an option to bear in mind | 15:08:05 |
| emily | I think the focus right now is more on getting new users off it and explicitly signalling deprecation than immediate removal though | 15:08:19 |
| emily | but given that useNetworkd is a seamless switch for probably >95% of existing users of the interface I'm also not sure there'll be much desire to keep the scripted code around for too long after flipping the default backend for that stuff | 15:09:04 |
 K900 | Honestly | 15:09:51 |
| Molly Miller | my colleagues are a little skeptical of networkd given that in the past the official answer from upstream regarding online reconfiguration has been "just reboot", which is a bit impractical when you have several racks full of servers which each take several minutes to boot, though i'm aware that networkd has grown much better online reconfiguration functionality in recent years | 15:09:52 |
| K900 | I don't even know the size of your org | 15:09:56 |
| emily | (Matrix ID is a hint :p) | 15:10:08 |
| K900 | But I can promise you porting to networkd will be less pain than maintaining networking.interfaces | 15:10:12 |
| Molly Miller | :) | 15:10:14 |
| emily | I'm unconvinced scripted networking has advantages over networkd in that area in 2025 | 15:10:47 |
| emily | there is also IfState | 15:10:57 |
| emily | we have no integration for that but if you don't like networkd maybe it might be an interesting migration target | 15:11:10 |
| Molly Miller | if networkd can handle online interface renaming then it's probably doable | 15:11:26 |
 hexa | no, that's a udev skill | 15:11:38 |
| hexa | still requires rebooting | 15:11:41 |
| emily | and RFC 42 style integration for that seems like something we'd accept in NixOS | 15:11:43 |
| emily | networkd can rename interfaces | 15:11:56 |
| emily | but maybe I misunderstand | 15:12:21 |
| hexa | .links files where interface renaming happens are handled by udev | 15:12:37 |
| hexa | you would possibly need to retrigger udev to cause the rename to happen | 15:12:50 |
| hexa | there are more interesting ways to shoot yourself in the foot | 15:13:06 |
| Molly Miller | the last time i looked at this 12-18 months ago, retriggering udev wouldn't rename the interfaces, that codepath was only triggered when they get added to the system for the first time | 15:13:34 |
| Molly Miller | the reasoning behind all of this is that our servers all have 4+ network interface each, so we name interfaces by function, and sometimes the interface assignment does change | 15:14:48 |
| K900 | That sounds like you should just use networkd link names for? | 15:15:41 |
| emily | links = {
"10-sfp-lan" = {
matchConfig.Property = [ "OF_FULLNAME=/soc/ethernet@15100000/mac@1" ];
linkConfig.Name = "sfp-lan";
};
"10-sfp-wan" = {
matchConfig.Property = [ "OF_FULLNAME=/soc/ethernet@15100000/mac@2" ];
linkConfig.Name = "sfp-wan";
};
};
| 15:16:00 |
| emily | I don't know if you can change this config and have stuff get re-assigned on the fly though which I guess is the question | 15:16:11 |
| Molly Miller | does that set the interface name properties or does that rename the kernel device? | 15:16:14 |
