From mboxrd@z Thu Jan 1 00:00:00 1970 Return-Path: Received: from firstgate.proxmox.com (firstgate.proxmox.com [212.224.123.68]) by lore.proxmox.com (Postfix) with ESMTPS id B49DE1FF179 for ; Wed, 12 Nov 2025 12:26:18 +0100 (CET) Received: from firstgate.proxmox.com (localhost [127.0.0.1]) by firstgate.proxmox.com (Proxmox) with ESMTP id 114801FF61; Wed, 12 Nov 2025 12:27:06 +0100 (CET) Message-ID: <01e0d96b-b970-4bff-bf7b-6bbd19c8e732@proxmox.com> Date: Wed, 12 Nov 2025 12:27:03 +0100 MIME-Version: 1.0 User-Agent: Mozilla Thunderbird To: Thomas Lamprecht , Proxmox Datacenter Manager development discussion , Hannes Laimer References: <20251110172517.335741-1-h.laimer@proxmox.com> <20251110172517.335741-11-h.laimer@proxmox.com> Content-Language: en-US From: Stefan Hanreich In-Reply-To: X-SPAM-LEVEL: Spam detection results: 0 AWL 0.724 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" On 11/12/25 12:21 PM, Thomas Lamprecht wrote: > 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. Yeah, the only benefit would be mirroring the PVE API, but there's a good argument against that here. _______________________________________________ pdm-devel mailing list pdm-devel@lists.proxmox.com https://lists.proxmox.com/cgi-bin/mailman/listinfo/pdm-devel