From mboxrd@z Thu Jan 1 00:00:00 1970 Return-Path: Received: from mp11.migadu.com ([2001:41d0:403:4789::]) (using TLSv1.3 with cipher TLS_AES_256_GCM_SHA384 (256/256 bits)) by ms9.migadu.com with LMTPS id wPt0CzXS7GRD0gAA9RJhRA:P1 (envelope-from ) for ; Mon, 28 Aug 2023 18:58:29 +0200 Received: from aspmx1.migadu.com ([2001:41d0:403:4789::]) (using TLSv1.3 with cipher TLS_AES_256_GCM_SHA384 (256/256 bits)) by mp11.migadu.com with LMTPS id wPt0CzXS7GRD0gAA9RJhRA (envelope-from ) for ; Mon, 28 Aug 2023 18:58:29 +0200 Received: from lists.gnu.org (lists.gnu.org [209.51.188.17]) (using TLSv1.2 with cipher ECDHE-RSA-AES256-GCM-SHA384 (256/256 bits)) (No client certificate requested) by aspmx1.migadu.com (Postfix) with ESMTPS id C4F6C4F5AA for ; Mon, 28 Aug 2023 18:58:28 +0200 (CEST) Authentication-Results: aspmx1.migadu.com; dkim=fail ("headers rsa verify failed") header.d=mmer.org header.s=dkim header.b=nQ7eJ08F; spf=pass (aspmx1.migadu.com: domain of "guix-patches-bounces+larch=yhetil.org@gnu.org" designates 209.51.188.17 as permitted sender) smtp.mailfrom="guix-patches-bounces+larch=yhetil.org@gnu.org"; dmarc=pass (policy=none) header.from=gnu.org ARC-Message-Signature: i=1; a=rsa-sha256; c=relaxed/relaxed; d=yhetil.org; s=key1; t=1693241908; h=from:from:sender:sender:reply-to:reply-to:subject:subject:date:date: message-id:message-id:to:to:cc:cc:mime-version:mime-version: content-type:content-type: content-transfer-encoding:content-transfer-encoding:resent-cc: resent-from:resent-sender:resent-message-id:in-reply-to:in-reply-to: references:references:list-id:list-help:list-unsubscribe: list-subscribe:list-post:dkim-signature; bh=bIMlaIkrBWu+00FsRa2cVURh9VRNWwLz2SJ+XisRFX4=; b=iyPbihSiOzFgECIM5eupXGB0xoC0mIBJ1LjMIOiwhhDBNHUmlY6gH+1lUCDE9TjOoYyjy4 i3Klad7OL1wB1lKc3cWyERzoZR6tDY2Uosk7s1oGax1YO1vJ9oRFoyvWVDHygUQpEajA6W Lv1jUtmwcReSEHcxE3gXovs9IwhKvHRwMJ87eRAJKUQdANyF3iVur52RS5X8WOqXo/E8T4 LwABG+o6R8/A1a09gZrRUpWZCRE7GPMPqBTvyglVgi5U/yU44abc9D8qvSxSbO48QVBThC LNGthhtNOt4WuhLUnHrul88b7h1e0CmMFOPvNEtkLd0HLriNuGtFODTEMUJudw== ARC-Seal: i=1; s=key1; d=yhetil.org; t=1693241908; a=rsa-sha256; cv=none; b=onydXcLgmQ2K0WlVCKh4J2d1qPCQj3AOwMSFVSBN7ho2CjwTuZETizb2CsNu8BolWsimxG e/noTcngEybutVC5l1q/gniM0+7Or6pRp+8Gxme7+AAJVc7gFrBrcl/d5+ErJMrCRzcnbu kVq1wokTCeSel9NVpinmo8TIDDxpmYUZcbP7SHM0Yt4+rgmkKyWXOLiZ9e6HORu7cJ0xcl E/BdGqhNVfZgDlpbBcbTCvT2KQ1aIgFR6ES2GT//7CTUEQmgFX0n1sn1Y1kRWJDek5aj7/ G7T7k9g6LDRumuTg9ZZL4fiAv2LQxcXXh387UFzzenTBWN5hkfmPjWlf3TavCg== ARC-Authentication-Results: i=1; aspmx1.migadu.com; dkim=fail ("headers rsa verify failed") header.d=mmer.org header.s=dkim header.b=nQ7eJ08F; spf=pass (aspmx1.migadu.com: domain of "guix-patches-bounces+larch=yhetil.org@gnu.org" designates 209.51.188.17 as permitted sender) smtp.mailfrom="guix-patches-bounces+larch=yhetil.org@gnu.org"; dmarc=pass (policy=none) header.from=gnu.org Received: from localhost ([::1] helo=lists1p.gnu.org) by lists.gnu.org with esmtp (Exim 4.90_1) (envelope-from ) id 1qafYq-0006wR-Gq; Mon, 28 Aug 2023 12:57:56 -0400 Received: from eggs.gnu.org ([2001:470:142:3::10]) by lists.gnu.org with esmtps (TLS1.2:ECDHE_RSA_AES_256_GCM_SHA384:256) (Exim 4.90_1) (envelope-from ) id 1qafYp-0006wG-SZ for guix-patches@gnu.org; Mon, 28 Aug 2023 12:57:55 -0400 Received: from debbugs.gnu.org ([2001:470:142:5::43]) by eggs.gnu.org with esmtps (TLS1.2:ECDHE_RSA_AES_128_GCM_SHA256:128) (Exim 4.90_1) (envelope-from ) id 1qafYp-0002Vh-KV for guix-patches@gnu.org; Mon, 28 Aug 2023 12:57:55 -0400 Received: from Debian-debbugs by debbugs.gnu.org with local (Exim 4.84_2) (envelope-from ) id 1qafYw-0003E8-2E for guix-patches@gnu.org; Mon, 28 Aug 2023 12:58:02 -0400 X-Loop: help-debbugs@gnu.org Subject: [bug#64616] [PATCH 0/1] services: static-networking: Add support for bonds and vlans Resent-From: Alexey Abramov Original-Sender: "Debbugs-submit" Resent-CC: guix-patches@gnu.org Resent-Date: Mon, 28 Aug 2023 16:58:02 +0000 Resent-Message-ID: Resent-Sender: help-debbugs@gnu.org X-GNU-PR-Message: followup 64616 X-GNU-PR-Package: guix-patches X-GNU-PR-Keywords: patch To: Ludovic =?UTF-8?Q?Court=C3=A8s?= Cc: Julien Lepiller , 64616@debbugs.gnu.org Received: via spool by 64616-submit@debbugs.gnu.org id=B64616.169324187112384 (code B ref 64616); Mon, 28 Aug 2023 16:58:02 +0000 Received: (at 64616) by debbugs.gnu.org; 28 Aug 2023 16:57:51 +0000 Received: from localhost ([127.0.0.1]:48932 helo=debbugs.gnu.org) by debbugs.gnu.org with esmtp (Exim 4.84_2) (envelope-from ) id 1qafYl-0003Dg-4J for submit@debbugs.gnu.org; Mon, 28 Aug 2023 12:57:51 -0400 Received: from mail.mmer.org ([178.22.65.174]:42462) by debbugs.gnu.org with esmtp (Exim 4.84_2) (envelope-from ) id 1qafYi-0003DR-B6 for 64616@debbugs.gnu.org; Mon, 28 Aug 2023 12:57:49 -0400 Received: from mail.mmer.org (localhost [127.0.0.1]) by mail.mmer.org (OpenSMTPD) with ESMTP id 517c1f96; Mon, 28 Aug 2023 16:57:34 +0000 (UTC) DKIM-Signature: v=1; a=rsa-sha256; c=relaxed; d=mmer.org; h=from:to:cc :subject:in-reply-to:references:date:message-id:mime-version :content-type:content-transfer-encoding; s=dkim; bh=ZGm71SLSUtHj 0fDMwcBcm9m9V9NVxDkE4AmoJH08hhk=; b=nQ7eJ08FSGBp8JbjK3RS8jeYYS2T GWVUXUE7hSI910uVkNZ235UezC0ORD7Zhatyx4jSd6zBv0KuSy/HocKbcDBX3han 17dHYoK3irrE9PQQE3SLvpDxWmhWQoVF3BuN9U0GvJn6umkOo5bAFckHUpRg+03M l2LrF1xiuBEUF20= Received: from delta.lan (i60212.upc-i.chello.nl [62.195.60.212]) by mail.mmer.org (OpenSMTPD) with ESMTPSA id ca71e0ec (TLSv1.3:TLS_AES_256_GCM_SHA384:256:NO); Mon, 28 Aug 2023 16:57:34 +0000 (UTC) In-Reply-To: <87350of1is.fsf_-_@gnu.org> ("Ludovic =?UTF-8?Q?Court=C3=A8s?="'s message of "Sat, 12 Aug 2023 22:28:59 +0200") References: <20230714152958.22645-1-levenson@mmer.org> <20230714153638.23768-1-levenson@mmer.org> <87350of1is.fsf_-_@gnu.org> Date: Mon, 28 Aug 2023 18:57:32 +0200 Message-ID: <87r0nnt88z.fsf@delta.lan> User-Agent: Gnus/5.13 (Gnus v5.13) MIME-Version: 1.0 Content-Type: text/plain; charset=utf-8 Content-Transfer-Encoding: quoted-printable X-BeenThere: debbugs-submit@debbugs.gnu.org X-Mailman-Version: 2.1.18 Precedence: list X-BeenThere: guix-patches@gnu.org List-Id: List-Unsubscribe: , List-Archive: List-Post: List-Help: List-Subscribe: , Reply-to: Alexey Abramov X-ACL-Warn: , Alexey Abramov via Guix-patches From: Alexey Abramov via Guix-patches via Errors-To: guix-patches-bounces+larch=yhetil.org@gnu.org Sender: guix-patches-bounces+larch=yhetil.org@gnu.org X-Migadu-Flow: FLOW_IN X-Migadu-Country: US X-Migadu-Spam-Score: -5.22 X-Spam-Score: -5.22 X-Migadu-Queue-Id: C4F6C4F5AA X-Migadu-Scanner: mx1.migadu.com X-TUID: Y2vpNh1OWCL3 Hi Ludo, Julien Ludovic Court=C3=A8s writes: > Hi Alexey, > > Alexey Abramov skribis: > >> * gnu/services/base.scm (, >> ): Provide records to match *existing* >> interfaces and amend them. >> * gnu/services/base.scm (network-set-up/linux, >> network-tear-down/linux): Add support to change settings of existing >> interfaces. Move address cleanup above links cleanup. >> * doc/guix.texi (Networking Setup): Document it. >> * gnu/tests/networking.scm (run-static-networking-advanced-test): Add te= sts > > Sounds like a great addition! > > Not being a networking expert, I=E2=80=99d like to have someone else comm= ent on > it (Cc=E2=80=99ing Julien in case they=E2=80=99re around), but I can make= some > preliminary comments: Many thanks!=20 >> @deftp {Data Type} network-link >> Data type for a network link (@pxref{Link,,, guile-netlink, >> -Guile-Netlink Manual}). >> +Guile-Netlink Manual}). A new interface with settings, specified in >> +arguments will be created. > > I don=E2=80=99t understand this sentence, especially since creating a > record will not create a new interface. Yeah. You right. I somehow got an impression that network-link is for link-add. No comments. ) [...] > My first reaction is that a =E2=80=9Cnetwork link matched by MAC address= =E2=80=9D is > still =E2=80=9Ca network link=E2=80=9D. IOW, I would find it more natura= l to have a > single data type; it would also mirror the data types used by the > RTnetlink layer. > > To do that, what would you think of keeping just the > record, but adding two new fields: =E2=80=98for-mac-address=E2=80=99 and > =E2=80=98for-device=E2=80=99? > > (As an aside, please don=E2=80=99t abbreviate; so =E2=80=98mac-address=E2= =80=99 rather than > =E2=80=98macaddress=E2=80=99.) I like that, thanks. I have a patch series where you can define the configuration like this: --8<---------------cut here---------------start------------->8--- (list (network-link (name "bond0") (type "bond") (arguments '((mode . "802.3ad") (miimon . 100) (lacp-active . "on") (lacp-rate . "fast")))) (network-link (for-mac-address "98:11:22:33:44:55") (arguments '((name . "a") (master . "bond0")))) (network-link (for-mac-address "98:11:22:33:44:56") (arguments '((name . "b") (master . "bond0")))) (network-link (name "bond0.1055") (type "vlan") (arguments '((id . 1055) (link . "bond0"))))) --8<---------------cut here---------------end--------------->8--- Is that what you meant? However, after your suggestions... What do you think if we could use the name field without type to amend existing ones, and for example netlink with mac-address field only, to match interfaces by mac. Something like this: --8<---------------cut here---------------start------------->8--- (list (network-link (mac-address "98:11:22:33:44:55") (arguments '((name . "a")))) (network-link (mac-address "98:11:22:33:44:56") (arguments '((name . "b")))) (network-link (name "bond0") (type "bond") (arguments '((mode . "802.3ad") (miimon . 100) (lacp-active . "on") (lacp-rate . "fast")))) =20=20=20=20=20=20 (network-link (name "a") (arguments '((master . "bond0")))) (network-link (name "b") (arguments '((master . "bond0")))) (network-link (name "bond0.1055") (type "vlan") (arguments '((id . 1055) (link . "bond0"))))) --8<---------------cut here---------------end--------------->8--- IMHO this does look better. What do you think?=20 >> +Here is another example for more advance configuration with bonds and >> +vlans. The following snippet will create a bond out of two interfaces, >> +rename the slaves and create a vlan 1055 on top of it. > > Could you (1) explain in one or two sentences what bonds and VLANs are, > ideally with a cross-reference to learn more about it, and (2) explain > the example in a bit more detail? Got it, will do. > I would also encourage you to use the =E2=80=9Cupstream=E2=80=9D and =E2= =80=9Cdownstream=E2=80=9D > rather than =E2=80=9Cmaster=E2=80=9D and =E2=80=9Cslave=E2=80=9D, due to = their obvious connotation, > though I realize that Guile-Netlink and presumably Linux/RTnetlink > itself use that terminology. I see. The technology is indeed uses this exact connotation. Documentation [1] itself also uses these terms. I personally, don't see how this change will help people with configuration or searching for documentation. With all respect, truly, I would like to keep master/slave terminology, at least here. > This is awesome! ) I am trying.=20 --=20 Alexey Footnotes: [1] https://www.kernel.org/doc/Documentation/networking/bonding.txt