From mboxrd@z Thu Jan 1 00:00:00 1970 Return-Path: Received: from firstgate.proxmox.com (firstgate.proxmox.com [IPv6:2a01:7e0:0:424::9]) by lore.proxmox.com (Postfix) with ESMTPS id 3C25D1FF179 for ; Wed, 12 Nov 2025 12:21:33 +0100 (CET) Received: from firstgate.proxmox.com (localhost [127.0.0.1]) by firstgate.proxmox.com (Proxmox) with ESMTP id 93C691FD39; Wed, 12 Nov 2025 12:22:20 +0100 (CET) Message-ID: Date: Wed, 12 Nov 2025 12:22:17 +0100 MIME-Version: 1.0 User-Agent: Mozilla Thunderbird Beta To: Proxmox Datacenter Manager development discussion , Stefan Hanreich , Hannes Laimer References: <20251110172517.335741-1-h.laimer@proxmox.com> <20251110172517.335741-11-h.laimer@proxmox.com> Content-Language: en-US From: Thomas Lamprecht In-Reply-To: X-Bm-Milter-Handled: 55990f41-d878-4baa-be0a-ee34c49e34d2 X-Bm-Transport-Timestamp: 1762946512499 X-SPAM-LEVEL: Spam detection results: 0 AWL -0.024 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 SPF_HELO_NONE 0.001 SPF: HELO does not publish an SPF Record SPF_PASS -0.001 SPF: sender matches SPF record Subject: Re: [pdm-devel] [PATCH proxmox-datacenter-manager v3 2/4] api: firewall: add option, rules and status endpoints X-BeenThere: pdm-devel@lists.proxmox.com X-Mailman-Version: 2.1.29 Precedence: list List-Id: Proxmox Datacenter Manager development discussion List-Unsubscribe: , List-Archive: List-Post: List-Help: List-Subscribe: , Reply-To: Proxmox Datacenter Manager development discussion Content-Type: text/plain; charset="us-ascii" Content-Transfer-Encoding: 7bit Errors-To: pdm-devel-bounces@lists.proxmox.com Sender: "pdm-devel" Am 12.11.25 um 11:52 schrieb Stefan Hanreich: > some comments inline > > On 11/10/25 6:25 PM, Hannes Laimer wrote: >> This adds the following endpoints >> * for all PVE remotes: >> - GET /pve/firewall/status >> >> * for PVE remotes >> - GET pve/remotes/{remote}/firewall/options >> - PUT pve/remotes/{remote}/firewall/options >> - GET pve/remotes/{remote}/firewall/rules >> - GET pve/remotes/{remote}/firewall/status >> >> * for PVE node >> - GET pve/remotes/{remote}/nodes/{node}/firewall/options >> - PUT pve/remotes/{remote}/nodes/{node}/firewall/options >> - GET pve/remotes/{remote}/nodes/{node}/firewall/rules >> - GET pve/remotes/{remote}/nodes/{node}/firewall/status >> >> * for guests (both lxc and qemu) >> - GET pve/remotes/{remote}/[lxc|qemu]/{vmid}/firewall/options >> - PUT pve/remotes/{remote}/[lxc|qemu]/{vmid}/firewall/options >> - GET pve/remotes/{remote}/[lxc|qemu]/{vmid}/firewall/rules > > Would it potentially make sense to mirror the PVE API here, i.e. > > pve/remotes/{remote}/nodes/{node}/[lxc|qemu]/{vmid}/firewall/options > > might be annoying to always have to know the node a guest resides on though That and I'm not sure about what the actual benefit of doing that would be here? Or just for using the same as in PVE? While I'd not promote deviating from existing product APIs, especially not just for the sake of it. OTOH leveraging what PDM can do and also avoiding historic mistakes that are either not worthwhile or just hard to fix in the original implementation can both be valid reason to deviate. _______________________________________________ pdm-devel mailing list pdm-devel@lists.proxmox.com https://lists.proxmox.com/cgi-bin/mailman/listinfo/pdm-devel