Hi all, Sorry for the delayed answer. I've been busy at many fronts.
And thanks so much to Lukas for friendly taking care of this topic. El 21/08/24 a las 10:30, Lukas Märdian escribió: > Hi Daniel, > > On 20.08.24 16:25, Daniel Gröber wrote: > > Hi Lukas, > > CCing d-devel, > > This email was intended to first gauge opinions from networking maintainers, > before pushing it out to debian-devel@l.d.o.. All the points still hold and > are fine to be public. But let me at least add the preamble and references > that you dropped from the email quotation. > > --- 8< --- > > On 20.08.24 12:58, Lukas Märdian wrote: > > Hi network maintainers! > > > > After our [Networking BoF] at DebConf24 in Busan I had the impression that > > Santiago is primarily interested in sunsetting classic ifupdown while > > avoiding > > to pull in any Python dependency into our base installations. I would like to rephrase my primary interest: replacing ifupdown with ifupdown-ng as soon as feasible (i.e., when it is ready). And yes, I would like to avoid that the decision that will come from this thread (we will decide something, right?) doesn't pull any python dependency. Switching the default network stack configuration tool is a semi-independent question. But in any case, I think that Debian would benefit for moving to something shared with other distros (netplan with Ubuntu, ifupdown-ng with Alpine Linux, ...) [snip] > > From previous discussion on debian-devel@l.d.o I also deduced that Daniel > > is > > interested in making ifupdown-ng a [drop-in replacement] for classic > > ifupdown, > > while the ifupdown2 maintainers are not interested in pushing their tool to > > become a default choice in Debian. I myself have been trying to introduce > > Netplan to a broader audience, after it got adopted by our [cloud-images] > > and > > integrated with [debian-installer]. > > --- 8< --- > > > tl;dr: I'm sorry to say I strongly oppose both removing ifupdown* in forky > > as well as raising netplan to Priority: standard. To move this forward > > without conflict I think we should base the default networking tool > > decision on data not developer opinion. > > In the end it still needs to be a developer decision, because someone needs > to do the work. Otherwise, we would be suffering the same way we did with > classic ifupdown in the past years, as it's becoming harder and harder to > maintain. We need a healthy upstream project and people willing to do the > actual maintenance work in Debian. > > Can you please elaborate why you're opposed to raising "netplan-generator" > to "Priority: standard"? That's independent of keeping ifupdown-ng installed > in Forky+ and I can't find any explanation about that in your comments below. > > > On Tue, Aug 20, 2024 at 12:58:28PM +0200, Lukas Märdian wrote: > > > So I want to find a compromise involving all interested parties. If there > > > are > > > no strong objections, I'd like to move forward with a proposal (and > > > change in > > > priorities via ftpmasters) that is structured as follows: > > > > > > * Keep ifupdown[-ng] installed (Priority: important) as a fallback and for > > > existing installations > > > - Replacing ifupdown with ifupdown-ng, if reaching a drop-in compatible > > > state is feasible in time for Trixie (@Daniel, what's you stance on > > > this?) > > > > If we can find enough testers, yes. The implementation work still to be > > done is small enough. I would be happy to discuss plans to find those testers. Probably we need to fix https://github.com/ifupdown-ng/ifupdown-ng/issues/216 first anyway. > > > - bluca is requesting ifupdown[-ng] to be dropped from the default > > > installation for Forky, which is sensible, IMO. But we also want to > > > keep > > > it around for a transitioning period (in Trixie), so that people > > > relying > > > on specific if-up/down.d hooks are covered and have plenty of time to > > > migrate to new tooling > > > > NACK. I'm not going to do the work to get ifupdown-ng into shape for being > > the default just to have it removed again that's a ridiculous ask. > > > > That being said I realise that without Santiago's support as ifupdown > > maintainer I don't have much of a procedural leg to stand on in opposing > > this. > > It wasn't an ask, the intention was to have it only if feasible, with > acceptable > efforts. Keeping classic ifupdown maintained for a transitioning period in > Trixie > would be an option, too, IMO. That's why we started forming the new "Debian > Networking Team" after our BoF discussions in Busan, so we could bundle > resources > and help each other out with critical maintenance & have a common channel for > communications. Testing new/compat functionality in ifupdown-ng could > certainly > fall into the same category where the [networking team] could provide support. > > Sunsetting classic ifupdown earlier and having a drop-in compatible > ifupdown-ng > would certainly be nicer, in order to reduce maintenance burden. And knowing > there > is a tool around that can be used by people relying on /etc/network/interfaces > longer term, even after it might (potentially) get dropped from the base > installation in Forky+. Daniel, there is a pending ifupdown upload that will change the Maintainer: to the Networking Team (*): https://salsa.debian.org/debian/ifupdown/-/commit/7e80ec63a32e443a460cd4a3d2aef9a8dc14015a. That change explicitly means that anything regarding ifupdown is a team decision :-). (*) On a side note, I think it would be great to define a policy for the team. But that is a matter for a separate thread. > > > * Keep sd-networkd installed (as part of the systemd package), becoming > > > the > > > recommended network config tool for minimal installations > > > - In debootstrap/chroots and also in minimal D-I installations (without > > > "standard utilities"),after the [networkd enablement] MR is landed > > > > NACK. I have a counter proposabl for this but let's focus the discussion > > the the idea below first. > > Yes! This was the original intention of my email. Please share your proposal > with > us, so we can discuss and find consensus. We shouldn't be holding things > back, as > after finding consensus we'll still need to implement stuff and also want to > have > some time for broad testing before Trixie releases. Daniel, could you please express your proposal? > > > I'd like to avoid drama and calling the CTTE to make a decision on our > > > behalf, but > > > rather find a compromise between us networking maintainers. So please let > > > me know > > > if this would work for you or if you have any alternative proposal(s). > > > > Frankly I think the problem we have here is that this shouldn't be a > > technical decision. We should focus on what the majority of our users > > actually want not our preferences. > > It is a technical decision. Utopia/Desktop maintainers made the decision to > use > NetworkManager. Cloud maintainers made the decision to use Netplan. And I > actually > talked to [D-I maintainers] about this before, as I though they'd be in a good > position to make this decision – but they didn't want to. So I started > reaching out > to the networking maintainers, about finding consensus. > > > I propose taking an informal vote on this to gather data on networking tool > > preference among DDs and the wider Debian community to settle > > this. @d-devel has this been done on decisions like these beore? How should > > we go about doing this? Would a GR be more appropriate? > > > > If it turns out I'm alone in wanting Debian to retain it's identity as > > Debian I will (grudingly) step aside on this matter, but in the absence of > > tangible data my current view is that this is not the case and I will take > > appropriate steps to protect that identity. > > Learning from the infamous systemd debate and [quoting former DPL Stefano], I > don't > think a GR is an appropriate approach: > > "GRs should be used for societal and policy decisions. Using GRs for > *technical* > decision is stupid. We really need to stop thinking that every single member > of the > Debian project, just because he/she is a DD, has a clue on every single > technical > matter that go on in the project." > > This is not a social nor political decision. It's about choosing a (very > techincal) > network stack. So I really hope we can figure it out between ourselves and > avoid > involving the CTTE, or anything else that will further delay a decision for > Trixie. > Technical is political (**) I am among those who think that any technical decision is bound to political and/or social consequences. And I don't think that is bad per se. Adopting netplan.io as the default network configuration tool in Debian would increase the dependency of Debian towards Ubuntu/Canonical and their business model, and any risk that it could carry on, including changes in licenses or adding a CLA requirement, as it happened with LXD [1]. But also with the benefits of having a funded upstream maintainer and the implicit engagement of full support during the whole ubuntu releases life-cycle. This could be evilly seen as giving some "power" to Canonical (an "ubuntuism", as mentioned in another email in the thread). But on the positive side, it is Debian benefiting from the contributions from a downstream, which is good, isn't it? (Disclaimer: I work for a company that aims at contributing as much as possible to Debian, and that is one of the things that I like about working for that company.) [1] https://github.com/canonical/lxd/pull/12663 https://github.com/canonical/lxd/pull/12665 An equivalent statement could be said about adopting ifupdown-ng, on any other option. Moving away from /etc/network/interfaces has an impact on the social, or rather emotional side of the "Debian identity". But providing our users with a more modern, flexible and better maintained tool is more important than the lose of that "identity". Classic ifupdown has some design issues that would require a core rewrite to be solved, which is no-sense today, given the alternatives. So yeah, we need to move away from it. (**) The first minutes of this presentation nicely represent my PoV about the statement: https://archive.fosdem.org/2017/schedule/event/network_measurement_ethics/ Coming back to a more technical side, I wanted to give this answer after doing a thorough review and comparison of the examples to configure different and complex network topologies in the different alternatives, but I have been unable to do it so far and I didn't want to delay this message any further. And, more importantly, (lazy question warning) is that comparison already been done? Does it make sense to do it? I have just started to test netplan (with netplan-generator only installed) on my machines, and will do the same with networkd and ifupdown-ng, so I can give a more informed (technical) judgment. So sorry, this is an incomplete answer. I am not giving my opinion about the way to move forward, yet. Just please, let's make this the last thread about the default network stack in future Debian releases. Cheers, -- Santiago
signature.asc
Description: PGP signature
