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 638EF1FF09B for ; Mon, 31 Aug 2026 14:41:54 +0200 (CEST) Received: from gate001.proxmox.com (localhost.localdomain [127.0.0.1]) by gate001.proxmox.com (Proxmox) with ESMTP id 24227213E5; Mon, 31 Aug 2026 14:41:54 +0200 (CEST) Message-ID: <3cca874f-e2a8-4c23-a802-9ac8855925ec@proxmox.com> Date: Mon, 31 Aug 2026 14:41:50 +0200 MIME-Version: 1.0 User-Agent: Mozilla Thunderbird Beta Subject: Re: [RFC PATCH datacenter-manager 2/2] ui: pve: load and use tag style overrides for resource tree To: Lukas Wagner , pdm-devel@lists.proxmox.com References: <20260417141237.2004866-1-d.csapak@proxmox.com> <20260417141237.2004866-2-d.csapak@proxmox.com> Content-Language: en-US From: Dominik Csapak In-Reply-To: Content-Type: text/plain; charset=UTF-8; format=flowed Content-Transfer-Encoding: 7bit X-Bm-Milter-Handled: 55990f41-d878-4baa-be0a-ee34c49e34d2 X-Bm-Transport-Timestamp: 1788180097233 X-SPAM-LEVEL: Spam detection results: 0 AWL 0.454 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) POISEN_SPAM_PILL 0.1 Meta: its spam POISEN_SPAM_PILL_1 0.1 random spam to be learned in bayes POISEN_SPAM_PILL_3 0.1 random spam to be learned in bayes 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: RXQPLV34BJM2JQ3FAHRZYX5AWOLE7PPF X-Message-ID-Hash: RXQPLV34BJM2JQ3FAHRZYX5AWOLE7PPF X-MailFrom: d.csapak@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 X-Mailman-Version: 3.3.10 Precedence: list List-Id: Proxmox Datacenter Manager development discussion List-Help: List-Owner: List-Post: List-Subscribe: List-Unsubscribe: On 8/31/26 2:17 PM, Lukas Wagner wrote: > On Fri Apr 17, 2026 at 4:10 PM CEST, Dominik Csapak wrote: >> This loads the tag style overrides (currently only the color), from >> /cluster/options once per remote when the remotes panel is opened, >> and uses the color-map to change the appearance of the tags. >> >> Since the /cluster/options return value is just a `Value` currently, >> introduce our own `TagStyle` and `DataCenterOptions` struct for parsing. >> (This can be dropped when we update the return schema and types in >> pve-manager and redo the return type in the pdm api) >> >> These will be converted into a `TagStyleOverride` struct that contains >> the necessary infos and interfaces and can be cloned cheaply (as it uses >> an Rc for the internal HashMap) so that we can easily move this around >> in the code, e.g. into closures and callbacks. >> >> The only downside to this is, that the global tree (e.g. in the search >> bar or a view) does not have these overrides and the tags can be >> different. > > I think having a consistent style for tags would be quite important; to > me, the style really is part of the 'identity' of the tag. > > In my opinion, either the entire PDM UI should properly respects the > overrides that were configured in PVE, or not at all. Having two visual > styles for the same tag is really not great, I think. I agree, i wasn't really happy with that split anyway... > > That raises the overall question about tag 'identity'. Should PDM > consider two tags with the same name (e.g. 'debian') from two remotes as > the same? I would argue strongly argue in favor of that, and I'd also > say that they should have the same style then. mhmm this is a tricky question, e.g. for a user that is 'owner' of all remotes this makes totally sense, but consider e.g. the "MSP" case, where a company has added the remotes of all their customers. there each customer might have different meaning for tags, and overlap 'by accident' would lump them together in pdm. not saying we couldn't do that anyway. but maybe having some sort of tag mapping (at least as an option) could maybe be necessary before simply treating tags from all remotes the same > > So, as a conclusion, I believe that tag style overrides should not be > per-remote, but 'global' to PDM, applying to all remotes. To make this > nicer for users, we could > > - allow importing existing overrides from PVE remotes (with the option > to decide what happens if any imported style would override an > existing definition) seems good to me (not sure about the ux yet, but makes sense) > - allow applying configured overrides to remotes what do you mean? copying the pdm local applied overrides to some remote? > > > What do you think? > > >> >> Signed-off-by: Dominik Csapak >> --- >> Not sure if we want to use the per remote color/style overrides in PDM >> at all, so I only included the color for now and sent as RFC. If we want >> to include the style, sorting, etc. it should be easy to include. >> >> If we want this, I'd also go and fix the return types in pve-manager, >> and update pve-api-types of course. Until then we could leave this in as >> a stopgap. >> > > Btw, this patch does not apply any more. > > Thanks! yes, no worries, i wanted to avoid rebasing work before getting any feedback at all ;)