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 325D71FF138 for ; Tue, 21 Jul 2026 11:24:47 +0200 (CEST) Received: from gate001.proxmox.com (localhost.localdomain [127.0.0.1]) by gate001.proxmox.com (Proxmox) with ESMTP id 480E6214B1; Tue, 21 Jul 2026 11:24:46 +0200 (CEST) Mime-Version: 1.0 Content-Transfer-Encoding: quoted-printable Content-Type: text/plain; charset=UTF-8 Date: Tue, 21 Jul 2026 11:24:10 +0200 Message-Id: To: "Ciro Iriarte" From: "Max R. Carrara" Subject: Re: [PATCH common/manager/proxmox-widget-toolkit/storage v2 00/17] GUI Support for Custom Storage Plugins X-Mailer: aerc 0.18.2-0-ge037c095a049 References: <20260717154943.696411-1-m.carrara@proxmox.com> <6a5bc3b4.481afadf.9e047.5039@mx.google.com> In-Reply-To: <6a5bc3b4.481afadf.9e047.5039@mx.google.com> X-Bm-Milter-Handled: 55990f41-d878-4baa-be0a-ee34c49e34d2 X-Bm-Transport-Timestamp: 1784625824415 X-SPAM-LEVEL: Spam detection results: 0 AWL 0.033 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) RCVD_IN_DNSWL_LOW -0.7 Sender listed at https://www.dnswl.org/, low 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: E6PUTSVRQ4YF6P42RDZA6CSASUDV5S2G X-Message-ID-Hash: E6PUTSVRQ4YF6P42RDZA6CSASUDV5S2G X-MailFrom: m.carrara@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 CC: pve-devel@lists.proxmox.com X-Mailman-Version: 3.3.10 Precedence: list List-Id: Proxmox VE development discussion List-Help: List-Owner: List-Post: List-Subscribe: List-Unsubscribe: On Sat Jul 18, 2026 at 8:19 PM CEST, Ciro Iriarte wrote: > Hi Max, > > Since I'm the one who asked for the advanced hint, I should say plainly > that x-advanced and x-hidden are worth keeping, in case the RFC marking > makes them look optional. > > From a third-party plugin author's side this is the difference between an > operator seeing a dozen fields with the four that matter buried among > them, and seeing four fields with a collapsible Advanced section. My > plugin carries management endpoint, credentials, pool, ldev_range, > host_group_prefix, control_plane, QoS limits and consistency-group > options; most deployments touch the endpoint, credentials and pool and > never look at the rest. Without a hint, every one of those is equally > prominent, and the hardcoded advanced list can't help since it only knows > about inbuilt properties. > > On patternProperties as the mechanism I have no strong opinion -- that's > a JSONSchema.pm call and you're better placed to make it. A plain > allowlist of known x- keywords would serve me identically. My interest is > only in the capability surviving in some form. Hi Ciro! Thanks a lot for your input, it's really valuable for us to know what custom plugin authors would like to see in that regard. The x-advanced and x-hidden keywords will definitely survive in one way or another; if we decide not to go forward with the patternProperties approach, I'll probably implement them in the same manner as sensitive properties, that is, being able to specify them in `plugindata()`. > > On 'sensitive': I'd expect it in the default schema rather than as an x- > keyword. It describes a property of the data rather than a UI hint, and > the ACME case you mentioned suggests it'll have more than one consumer. Yeah that's a good point, though ideally I'd like to add such a keyword as part of a custom vocabulary [vocab] instead (or something similar). In any case, it's bound to stay in one form or another. > > On testing: I'll validate against pve-FCLUPlugin once this lands in the > repo, rather than per-revision while it's still in review -- so expect > feedback from me after it's merged, not a Tested-by on v2. ACK, sounds good! Thanks a lot! There shouldn't really be too many surprises anyway, since the core logic is pretty fleshed out at this point, I'd say. > > Thanks, > Ciro - Max [vocab] https://json-schema.org/draft/2020-12/json-schema-core#name-schema-= vocabularies