From mboxrd@z Thu Jan 1 00:00:00 1970 Return-Path: Received: from gate001.proxmox.com (gate001.proxmox.com [IPv6:2a0f:8001:1:32::40]) by lore.proxmox.com (Postfix) with ESMTPS id 8452E1FF0AE for ; Tue, 01 Sep 2026 09:14:41 +0200 (CEST) Received: from gate001.proxmox.com (localhost.localdomain [127.0.0.1]) by gate001.proxmox.com (Proxmox) with ESMTP id B2874214D9; Tue, 01 Sep 2026 09:14:40 +0200 (CEST) Date: Tue, 1 Sep 2026 09:14:36 +0200 From: Hannes Laimer To: Daniel Herzig Subject: Re: [pve-network v2 1/4] vnets: introduce get_subnets_with_config Message-ID: References: <20260831110116.300798-1-d.herzig@proxmox.com> <20260831110116.300798-2-d.herzig@proxmox.com> <87ecfe1hd3.fsf@proxmox.com> MIME-Version: 1.0 Content-Type: text/plain; charset=us-ascii Content-Disposition: inline In-Reply-To: <87ecfe1hd3.fsf@proxmox.com> X-Bm-Milter-Handled: 55990f41-d878-4baa-be0a-ee34c49e34d2 X-Bm-Transport-Timestamp: 1788246875122 X-SPAM-LEVEL: Spam detection results: 0 AWL 0.773 Adjusted score from AWL reputation of From: address DMARC_MISSING 0.1 Missing DMARC policy KAM_DMARC_STATUS 0.01 Test Rule for DKIM or SPF Failure with Strict Alignment (newer systems) RCVD_IN_DNSWL_MED -2.3 Sender listed at https://www.dnswl.org/, medium trust SPF_HELO_NONE 0.001 SPF: HELO does not publish an SPF Record SPF_PASS -0.001 SPF: sender matches SPF record Message-ID-Hash: QYLW7FIIJFWK7QLGGLGXZIEOYSLDES3C X-Message-ID-Hash: QYLW7FIIJFWK7QLGGLGXZIEOYSLDES3C X-MailFrom: h.laimer@proxmox.com X-Mailman-Rule-Misses: dmarc-mitigation; no-senders; approved; loop; banned-address; emergency; member-moderation; nonmember-moderation; administrivia; implicit-dest; max-recipients; max-size; news-moderation; no-subject; digests; suspicious-header CC: pve-devel@lists.proxmox.com X-Mailman-Version: 3.3.10 Precedence: list List-Id: Proxmox VE development discussion List-Help: List-Owner: List-Post: List-Subscribe: List-Unsubscribe: On 2026-08-31 16:42, Daniel Herzig wrote: > > > Hannes Laimer writes: > > > On 2026-08-31 13:01, Daniel Herzig wrote: > >> Add 'get_subnets_with_config' to return the subnets of a vnet with > >> certain subnet configuration and integrate into the current > >> 'get_subnets'. > >> > >> This allows to keep the original behaviour of 'get_subnets' -- > >> retrieving subnet configurations (retreiving it either from the > >> running sdn-config, or from the 'subnets.cfg' config file) when it's > >> not available to the caller -- without doubling doubling up the code > >> to to loop through the subnet ids to handle the other case (subnet > >> configuration already present at the callsite). > >> > >> Suggested-by: Gabriel Goller > >> Suggested-by: Hannes Laimer > >> Signed-off-by: Daniel Herzig > >> --- > >> src/PVE/Network/SDN/Vnets.pm | 8 +++++++- > >> 1 file changed, 7 insertions(+), 1 deletion(-) > >> > >> diff --git a/src/PVE/Network/SDN/Vnets.pm b/src/PVE/Network/SDN/Vnets.pm > >> index c327a4b..aa2e842 100644 > >> --- a/src/PVE/Network/SDN/Vnets.pm > >> +++ b/src/PVE/Network/SDN/Vnets.pm > >> @@ -70,9 +70,15 @@ sub get_vnet { > >> sub get_subnets { > >> my ($vnetid, $running) = @_; > >> > >> - my $subnets = undef; > >> my $subnets_cfg = PVE::Network::SDN::Subnets::config($running); > >> + return get_subnets_with_config($vnetid, $subnets_cfg); > >> + > >> +} > >> > >> +sub get_subnets_with_config { > >> + my ($vnetid, $subnets_cfg) = @_; > >> + > > > > we should probably `die` here if the passed cfg is undef, for the > > deletion `ids` will be empty, and an empty conf will be generated, > > that's fine. but we dont want undef here.. > > I guess we could possibly also fall back to re-reading > `/etc/pve/sdn/subnets.cfg` in case anything got lost in transmission, or > in a disaster-situation, where the file got lost alltogether, fall back > to get the values from `.running-config` and issue a warning instead of > `die`-ing here. I need to wrap my head around it, but I'm not sure if > this is a good place to `die`. > not really, at least i don't think we should. the premis of this sub is, 'give me a config, and ill get you its subnets', the assertion here is 'you give me a config'. this should not go and fetch its own.. > > on that note, the guard in > > Dhcp.pm should maybe be updated > > > > I've sent a separate answer regarding the patch in Dhcp.pm -- in a > nutshell, we could possibly just skip that one (also, because it's not > really related to the dry-run topic). > > > >> + my $subnets = undef; > >> foreach my $subnetid (sort keys %{ $subnets_cfg->{ids} }) { > >> my $subnet = PVE::Network::SDN::Subnets::sdn_subnets_config($subnets_cfg, $subnetid); > >> next if !$subnet->{vnet} || ($vnetid && $subnet->{vnet} ne $vnetid); > >> -- > >> 2.47.3 > >> > >>