From mboxrd@z Thu Jan 1 00:00:00 1970 Return-Path: Received: from firstgate.proxmox.com (firstgate.proxmox.com [212.224.123.68]) (using TLSv1.3 with cipher TLS_AES_256_GCM_SHA384 (256/256 bits) key-exchange X25519 server-signature RSA-PSS (2048 bits)) (No client certificate requested) by lists.proxmox.com (Postfix) with ESMTPS id D28AF724C2 for ; Mon, 12 Apr 2021 15:15:11 +0200 (CEST) Received: from firstgate.proxmox.com (localhost [127.0.0.1]) by firstgate.proxmox.com (Proxmox) with ESMTP id C223D1F38F for ; Mon, 12 Apr 2021 15:14:41 +0200 (CEST) Received: from proxmox-new.maurer-it.com (proxmox-new.maurer-it.com [212.186.127.180]) (using TLSv1.3 with cipher TLS_AES_256_GCM_SHA384 (256/256 bits) key-exchange X25519 server-signature RSA-PSS (2048 bits)) (No client certificate requested) by firstgate.proxmox.com (Proxmox) with ESMTPS id E76CD1F377 for ; Mon, 12 Apr 2021 15:14:39 +0200 (CEST) Received: from proxmox-new.maurer-it.com (localhost.localdomain [127.0.0.1]) by proxmox-new.maurer-it.com (Proxmox) with ESMTP id A4CE545A2B for ; Mon, 12 Apr 2021 15:14:39 +0200 (CEST) From: Aaron Lauterer To: pve-devel@lists.proxmox.com Date: Mon, 12 Apr 2021 15:14:36 +0200 Message-Id: <20210412131438.15859-1-a.lauterer@proxmox.com> X-Mailer: git-send-email 2.20.1 MIME-Version: 1.0 Content-Transfer-Encoding: 8bit X-SPAM-LEVEL: Spam detection results: 0 AWL -0.015 Adjusted score from AWL reputation of From: address KAM_DMARC_STATUS 0.01 Test Rule for DKIM or SPF Failure with Strict Alignment 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 Subject: [pve-devel] [RFC series 0/2] Show more vlan infos X-BeenThere: pve-devel@lists.proxmox.com X-Mailman-Version: 2.1.29 Precedence: list List-Id: Proxmox VE development discussion List-Unsubscribe: , List-Archive: List-Post: List-Help: List-Subscribe: , X-List-Received-Date: Mon, 12 Apr 2021 13:15:11 -0000 The main motivation here is to make the VLAN tags configured for an interface better visible. The approach taken in this RFC is to use the already existing vlan-id and vlan-raw-device values. These were only present if the vlan device was configured with those explicit options, available with ifupdown2. For the other way, using the dot notation, the type was detected correctly, but no further information about the vlan id and the used device was present. Therefore the Inotify.pm has been changed to set the same values for the dot notation interfaces. This results in the API delivering the same information, not matter which type of vlan interface it is. Since the vlan-id and vlan-raw-device values are filtered for dot notation interfaces when writing out the network config, I don't see much harm here. But should this approach be problematic for some reason that I have not yet discovered, there is an alternative approach handling this in the GUI only. Then the GUI would show the same information for both type of vlan interfaces but the API would stay the same. widget-toolkit: Aaron Lauterer (1): ui: network: add columns for vlan-id and vlan-raw-device src/node/NetworkView.js | 14 ++++++++++++++ 1 file changed, 14 insertions(+) pve-common: src/PVE/INotify.pm | 8 ++++++-- 1 file changed, 6 insertions(+), 2 deletions(-) -- 2.20.1