Hi Vincent, Martin, On Thu, Jul 11, 2024 at 07:54:50AM +0200, Vincent Bernat wrote: > > From where I'm sitting ifupdown2 is completely out of the question as *the* > > Debian ifupdown since it doesn't even support *basic* IPv6 use-cases like > > DHCPv6. Upstream community seems nonexistant since this is software by a > > corp for a corp where community building was probably never the > > goal. Admittedly I didn't look very hard, this is just my impression > > currently. > > This is quite unfair. Cumulus tried very hard to make ifupdown2 a > community projects, with notably a presentation at Debconf 14 and Debconf > 16. [...] It never took as we prefer old broken software over something > not 100% compatible and also because it is written in Python and we > didn't want Python in the base installation. > > Since Cumulus has been bought by Nvidia, things have changed and development > of ifupdown2 is now done behind closed doors. See > https://github.com/CumulusNetworks/ifupdown2/pull/271#issuecomment-1706260260
Right, I wasnt around for those, my impressions are based on post-nvidia ifupdown2. That being said it doesn't change it's unfortunate current state. I don't see any community activity on *2 whereas *-ng has a fair bit and an impressive array of executors already with more coming https://github.com/ifupdown-ng/ifupdown-ng/tree/main/executor-scripts/linux > One of its killer feature is the ability to go from the running state to > the target state with one command (ifreload). Yeah I agree that's useful it would be nice if it can fit into ifupdown-ng's design but I think upstream made a good decision in not imposing the additional complexity to support it on the executors from the start. Maybe we can still add it. Someone more interested in that feature ought to have a look *hint* *hint* :) On Thu, Jul 11, 2024 at 11:23:38AM +0300, Martin-Éric Racine wrote: > > > Claiming to offer a drop-in substitute all while nudging people > > > towards a new paradigm is not welcome. > > > > If ifupdown's paradigm were working for people we wouldn't be having this > > conversation. > > The paradigm is working. I mean looking at the other half of this thread, clearly the ifupdown* paradigm isn't working at all for some people which I think is unfortunate. I just want to point out that -ng comes as a library too (which I haven't packaged separately yet) so integrating with /etc/network/interfaces and even the interface state should very much be possible for any other network managment tool that would want to. I still think you're making too much of this `use` feature. I had a conversation with upstream about it and took another look at the code and it's basically just an optimization to *only* run the delcared executors as opposed to all of them (in case any of their config stanzas are used). I think it may let you sidestep issues with if*.d stanza namespacing issues too, but that's about it. If you don't like it don't use it. I certainly have not had a need for it so far. > > How else would you move /etc/network/interfaces forward without breaking > > anything? > > I would really like to hear what is wrong with the current format. I'd like to hear what is wrong with making the current format more extensible with full legacy compatibility? The format is fine, but ofc. ifupdown-ng is going to extend it where it makes sense. > For my perspective, the main issues with ifupdown are: > > 1) ifupdown doesn't handle bridges and vlans without external > packages, yet it already depends upon iproute2, which provides 'ip' > i.e. a command that can handle these quite nicely. Not quite true, vlan support is now internal AFAIK, or at least I haven't installed `vlan` in ages and things seem to work :) The ifupdown-ng executors for vlan/ bridge support are here if you want to have a look: https://github.com/ifupdown-ng/ifupdown-ng/blob/main/executor-scripts/linux/link https://github.com/ifupdown-ng/ifupdown-ng/blob/main/executor-scripts/linux/bridge > 2) ifupdown doesn't include a way to handle DHCPv6-PD for all > supported DHCP clients. > > 3) Since the introduction of systemd units, one can no longer rely on > interfaces being brought up sequentially following the order in which > they appear in /etc/network/interfaces. ifupdown-ng's dependency resolution based "paradigm shift ;)" should make that unecessary, but perhaps that calls for another ifupdown-ng.conf option? Not sure. Why is the order important outside of the obvious master device dependencies? > 4) That systemd unit generation blissfully ignores anything else that > physical interfaces in /etc/network/interfaces which introduces yet > more reproducibility problems. Not sure what you're talking about here? --Daniel
signature.asc
Description: PGP signature
