From mboxrd@z Thu Jan 1 00:00:00 1970
Return-Path: <pve-devel-bounces@lists.proxmox.com>
Received: from firstgate.proxmox.com (firstgate.proxmox.com [212.224.123.68])
by lore.proxmox.com (Postfix) with ESMTPS id 5BA8F1FF15E
for <inbox@lore.proxmox.com>; Tue, 8 Apr 2025 20:43:25 +0200 (CEST)
Received: from firstgate.proxmox.com (localhost [127.0.0.1])
by firstgate.proxmox.com (Proxmox) with ESMTP id B4C1334D9C;
Tue, 8 Apr 2025 20:43:20 +0200 (CEST)
Message-ID: <6b9dd950-f2fe-4397-b5b6-09f4578abcc7@proxmox.com>
Date: Tue, 8 Apr 2025 20:43:17 +0200
MIME-Version: 1.0
User-Agent: Mozilla Thunderbird Beta
To: Proxmox VE development discussion <pve-devel@lists.proxmox.com>,
Stefan Hanreich <s.hanreich@proxmox.com>
References: <20250408163250.355449-1-s.hanreich@proxmox.com>
<20250408163250.355449-2-s.hanreich@proxmox.com>
Content-Language: en-GB
From: Thomas Lamprecht <t.lamprecht@proxmox.com>
In-Reply-To: <20250408163250.355449-2-s.hanreich@proxmox.com>
X-SPAM-LEVEL: Spam detection results: 0
AWL -0.036 Adjusted score from AWL reputation of From: address
BAYES_00 -1.9 Bayes spam probability is 0 to 1%
DMARC_MISSING 0.1 Missing DMARC policy
KAM_DMARC_STATUS 0.01 Test Rule for DKIM or SPF Failure with Strict Alignment
RCVD_IN_VALIDITY_CERTIFIED_BLOCKED 0.001 ADMINISTRATOR NOTICE: The query to
Validity was blocked. See
https://knowledge.validity.com/hc/en-us/articles/20961730681243 for more
information.
RCVD_IN_VALIDITY_RPBL_BLOCKED 0.001 ADMINISTRATOR NOTICE: The query to
Validity was blocked. See
https://knowledge.validity.com/hc/en-us/articles/20961730681243 for more
information.
RCVD_IN_VALIDITY_SAFE_BLOCKED 0.001 ADMINISTRATOR NOTICE: The query to
Validity was blocked. See
https://knowledge.validity.com/hc/en-us/articles/20961730681243 for more
information.
SPF_HELO_NONE 0.001 SPF: HELO does not publish an SPF Record
SPF_PASS -0.001 SPF: sender matches SPF record
URIBL_BLOCKED 0.001 ADMINISTRATOR NOTICE: The query to URIBL was blocked. See
http://wiki.apache.org/spamassassin/DnsBlocklists#dnsbl-block for more
information. [evpnplugin.pm]
Subject: Re: [pve-devel] [PATCH pve-network 1/1] frr: enable frr service on
reloading the controller config
X-BeenThere: pve-devel@lists.proxmox.com
X-Mailman-Version: 2.1.29
Precedence: list
List-Id: Proxmox VE development discussion <pve-devel.lists.proxmox.com>
List-Unsubscribe: <https://lists.proxmox.com/cgi-bin/mailman/options/pve-devel>,
<mailto:pve-devel-request@lists.proxmox.com?subject=unsubscribe>
List-Archive: <http://lists.proxmox.com/pipermail/pve-devel/>
List-Post: <mailto:pve-devel@lists.proxmox.com>
List-Help: <mailto:pve-devel-request@lists.proxmox.com?subject=help>
List-Subscribe: <https://lists.proxmox.com/cgi-bin/mailman/listinfo/pve-devel>,
<mailto:pve-devel-request@lists.proxmox.com?subject=subscribe>
Reply-To: Proxmox VE development discussion <pve-devel@lists.proxmox.com>
Content-Type: text/plain; charset="us-ascii"
Content-Transfer-Encoding: 7bit
Errors-To: pve-devel-bounces@lists.proxmox.com
Sender: "pve-devel" <pve-devel-bounces@lists.proxmox.com>
On 08/04/2025 18:32, Stefan Hanreich wrote:
> Since we now ship frr with Proxmox VE, the frr service is available on
> the nodes but disabled on install. Prior to that users had to manually
> install frr, which automatically enabled the service. When applying a
> SDN configuration with an EVPN controller, we invoke systemctl restart
> frr, which leads to the service running but still being in the
> disabled state. This means that the EVPN setup is working until the
> next reboot. To avoid the situation where users configure an EVPN
> controller and everything seems to be working, until a restart breaks
> the EVPN setup, additionally enable the frr service before restarting
> it.
>
> Signed-off-by: Stefan Hanreich <s.hanreich@proxmox.com>
> ---
> src/PVE/Network/SDN/Controllers/EvpnPlugin.pm | 1 +
> 1 file changed, 1 insertion(+)
>
> diff --git a/src/PVE/Network/SDN/Controllers/EvpnPlugin.pm b/src/PVE/Network/SDN/Controllers/EvpnPlugin.pm
> index c245ea2..4249cc5 100644
> --- a/src/PVE/Network/SDN/Controllers/EvpnPlugin.pm
> +++ b/src/PVE/Network/SDN/Controllers/EvpnPlugin.pm
> @@ -638,6 +638,7 @@ sub reload_controller {
> };
> if ($@) {
> warn "frr reload command fail. Restarting frr.";
> + run_command(['systemctl', 'enable', 'frr']);
can we guard this with an file exists check for
"/etc/systemd/system/multi-user.target.wants/frr.service"? Not a must, but does
not feel right to unconditionally call systemctl enable.
> eval { run_command(['systemctl', 'restart', 'frr']); };
> }
> }
_______________________________________________
pve-devel mailing list
pve-devel@lists.proxmox.com
https://lists.proxmox.com/cgi-bin/mailman/listinfo/pve-devel