[Date Prev][Date Next] [Thread Prev][Thread Next] [Date Index] [Thread Index]

Re: proposal: Hybrid network stack for Trixie



Le lundi, 23 septembre 2024, 13.04:41 h CEST Lukas Märdian a écrit :
> On 22.09.24 12:22, Chris Hofstaedtler wrote:
> > * Lukas Märdian <slyon@debian.org> [240920 13:13]:
> >> I've repeated the reasons why I think a hybrid stack using Netplan is a
> >> feasible solution many times in previous threads, therefore I'd like to
> >> refer to a list of frequently asked questions, instead of spreading more
> >> reasons across more replies: https://wiki.debian.org/Netplan/FAQ
> >> 
> >> # Why
> >> The ifupdown package is a Debian only solution that is becoming a
> >> maintenance burden. We've had plenty of discussions over the years and
> >> consensus is that we want to get rid of it.
> >> Some variations of Debian have already moved forward with choosing a
> >> different stack, such as desktop/laptop installations (using
> >> NetworkManager) and cloud images (using Netplan+systemd-networkd). Also,
> >> ifupdown-ng exists as a modern re-implementation of the classic tooling,
> >> that strives to become drop-in [compatible].
> > 
> > Thanks for providing the FAQ and this "Why" section, but it seems to
> > leave open why we would want or need netplan as the default. As the
> > FAQ shows, netplan is available as an optional package in many
> > distros. The same is already true in Debian thanks to you.
> 
> As described in the "Proposal" section and first answer of the FAQ, it's all
> about consistency.
> 
> There seems to be a tendency for moving towards a hybrid stack, using
> sd-networkd and NetworkManager in different contexts/use-cases. But having
> fragmented ways of doing network configuration provides bad UX, as it can
> confuse users, who first need to understand what sortf of Debian they are
> using, before looking for solutions.
> 
> Netplan solves this and allows for providing common solution that work
> across the system.
> 
> The Netplan tooling around that, like "netplan status" or "netplan try"
> to query/debug the network configuration or apply, but roll-back
> configuration, in case it did not work out as expected, are only added
> benefits.

It sounds like having netplan be *available for install* solves that nicely if 
one cares about consistency across their fleet of Debian hosts; just make sure 
(via d-i preseed, cloud-init, etc) to install netplan when bootstrapping 
machines/VM/hosts, and you're good to go, right?

I don't see any additional benefit by enforcing it on all installs by default, 
as has been eloquently explained already.

-- 
    OdyX

Attachment: signature.asc
Description: This is a digitally signed message part.


Reply to: