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 D5E841FF16F for ; Tue, 14 Oct 2025 11:19:46 +0200 (CEST) Received: from firstgate.proxmox.com (localhost [127.0.0.1]) by firstgate.proxmox.com (Proxmox) with ESMTP id E9AAF24A6C; Tue, 14 Oct 2025 11:20:04 +0200 (CEST) Message-ID: Date: Tue, 14 Oct 2025 11:20:02 +0200 MIME-Version: 1.0 User-Agent: Mozilla Thunderbird To: Dominik Csapak , Proxmox Datacenter Manager development discussion References: <20251013085623.211136-1-c.ebner@proxmox.com> <20251013085623.211136-6-c.ebner@proxmox.com> <1a9276dd-4d76-474f-be6e-3be61e0b281d@proxmox.com> Content-Language: en-US, de-DE From: Christian Ebner In-Reply-To: <1a9276dd-4d76-474f-be6e-3be61e0b281d@proxmox.com> X-Bm-Milter-Handled: 55990f41-d878-4baa-be0a-ee34c49e34d2 X-Bm-Transport-Timestamp: 1760433565776 X-SPAM-LEVEL: Spam detection results: 0 AWL 0.042 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 datacenter-manager 5/7] ui: dashboard: distinguish failed remotes based on remote type 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-Transfer-Encoding: 7bit Content-Type: text/plain; charset="us-ascii"; Format="flowed" Errors-To: pdm-devel-bounces@lists.proxmox.com Sender: "pdm-devel" On 10/14/25 10:47 AM, Dominik Csapak wrote: > more of a high level comment regarding the node dashboard component, but > it fits here as well as the previous patch: > > i believe we should rethink how we propagate the information > to this panel, so that we don't have to extract the correct information > inside > > e.g. either we restructure the api call/data in a way to separate > the info by type in the first place, or we do that directly > after the api call. > > either way I'd probably give this panel just a simple struct > with the necessary information to display > > I think this would make it a bit easier to follow and less > like that we forget to e.g. check the type for the content > > what do you say? Yes, agreed. Will keep the panel input data as simple as possible then. Fetching the status by remote type would be an option, but at the cost of an additional API call. Also the return data is already laid out to be cumulative over remote type variants. Therefore, maybe better to do the splitting of the remote type specific information after getting the status? Finally, splitting the `status` endpoint return data by type is nor really an option, since that would be a breaking API change, so better avoided. Thanks a lot for your comments! _______________________________________________ pdm-devel mailing list pdm-devel@lists.proxmox.com https://lists.proxmox.com/cgi-bin/mailman/listinfo/pdm-devel