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 7F8E81FF0E5 for ; Wed, 15 Jul 2026 16:54:06 +0200 (CEST) Received: from gate001.proxmox.com (localhost.localdomain [127.0.0.1]) by gate001.proxmox.com (Proxmox) with ESMTP id 1E21A21441; Wed, 15 Jul 2026 16:54:05 +0200 (CEST) Message-ID: <4d0f0ae5-5069-4aac-83f4-b9f1acfda0b5@proxmox.com> Date: Wed, 15 Jul 2026 16:53:59 +0200 MIME-Version: 1.0 User-Agent: Mozilla Thunderbird Beta Subject: Re: [PATCH common/manager/proxmox-widget-toolkit/storage 00/13] GUI Support for Custom Storage Plugins To: Ciro Iriarte , "Max R. Carrara" , pve-devel@lists.proxmox.com References: <20260623143402.772452-1-m.carrara@proxmox.com> <6a5791cb.f6216423.106138.670b@mx.google.com> Content-Language: en-US From: Thomas Lamprecht In-Reply-To: <6a5791cb.f6216423.106138.670b@mx.google.com> Content-Type: text/plain; charset=UTF-8 Content-Transfer-Encoding: 7bit X-Bm-Milter-Handled: 55990f41-d878-4baa-be0a-ee34c49e34d2 X-Bm-Transport-Timestamp: 1784127221753 X-SPAM-LEVEL: Spam detection results: 0 AWL 0.301 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: 5MDXYD4JCOUJEYDGW6XCJAOHZ6DIJBPF X-Message-ID-Hash: 5MDXYD4JCOUJEYDGW6XCJAOHZ6DIJBPF X-MailFrom: t.lamprecht@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 VE development discussion List-Help: List-Owner: List-Post: List-Subscribe: List-Unsubscribe: Hi Ciro, Thanks for your input here. Am 15.07.26 um 15:57 schrieb Ciro Iriarte: > For context: I had independently drafted an RFC for the same problem > (schema-driven storage dialog, Bugzilla #7808) before Dominik kindly > pointed me at this series. Our designs converge -- derive the dialog > from the already-registered SectionConfig property + options() rather > than duplicating a separate GUI schema -- and yours is already > implemented and tested, so there is no reason to carry a competing > proposal. I am closing #7808 as a duplicate of #3420 and consolidating > my requirements here instead. Big +1 on the direction. > > I maintain a third-party enterprise Fibre Channel plugin > (pve-FCLUPlugin, reference driver for Hitachi VSP) that today survives > by injecting JS into index.html.tpl -- exactly the workaround this > series removes -- so I have a concrete stake in it. The series already > covers the core (title/label, fixed->read-only, sensitive->Unchanged, > enum, multiline, min/max, defaults); everything below is a follow-up, > not a blocker. Prioritized by how much it decides whether an enterprise > plugin can drop its JS injection entirely: > > P1 -- Is a sanctioned escape hatch for custom widgets/validators in > scope, now or later? No, fully custom widgets are not in the scope. > Pure schema-derivation cannot express a "Test connection" button, an > async combo populated from the array (pool IDs, host groups), or a > cross-field validator. My worry is that without one blessed override > path, advanced plugins stay on index.html.tpl injection -- the very > thing this series eliminates -- for anything beyond simple fields. Would > you be open to a plugin registering an ExtJS component (e.g. a public > registerStoragePlugin() / xtype hook) that the generic panel uses when > present and falls back to schema derivation otherwise? For a plugin like > mine this is the item that decides whether the mechanism can be adopted > wholesale, so I would value your read on whether it belongs in this > series or a follow-up. Describing the main use-cases, like you already partially do above, is much more relevant for us here to advance this for all storage integrators. You can do already a lot of these in the plugins check_config method, while that might not provide the best possible UX, it's still can give concrete hints for feedback. index.html.tpl injections or the like might not be possible at all in the (not so far away) future, we actively work on expanding our rust based UI framework - that PDM already uses - to also support all common PVE widgets. And while switching to that is not exactly around the corner, it's also not multiple years in the future; a point release in the next major version is rather realistic. The schema based interfaces here will be the (only) official way to have UI support for when the switch happens. Note that this doesn't mean that crucial features from which UI/UX can benefit from isn't possible to integrate; e.g. a more integrated validation or connection test can be possible through adding a new, or expanding an existing, method provided by the storage plugin interface. If it exists the UI integration here can then e.g. signal that a live verification through the backend is possible and leverage that to provide nicer validation UX. That said, this is not something we strive to for the initial integration, just wanted to give you an example for how crucial tasks that really help to get basic UX right can be done without such custom plugins. > > P2 -- A per-property "advanced" (and optional group/section) hint for > custom plugins. > The advanced-section split is currently hardcoded for inbuilt > properties (preallocation, SAVC). Real drivers carry many options -- > mine has management endpoint, credentials, pool, ldev_range, > host_group_prefix, control_plane, QoS, consistency-group -- and a flat > field list buries the rarely-changed ones. Proposal: honor an > `advanced` (and optionally a `group`) key per property in the derived > schema, the same treatment inbuilt preallocation/SAVC already get. Tagging fields as advanced would be doable relatively easily, the other ones might be, but I'd first try to get the default layouting "algorithm" to present a somewhat OK layout, we can then build off from that once the initial integration is shipped and battle tested. A basic UI with a not so beautiful UI is still lots better than no UI at all. > P3 -- Conditional / dependent field visibility. > Many options are only meaningful given another: an Ops Center CM URL + > credentials only when control_plane = ops-center-cm, QoS limits only > when QoS is enabled. Static derivation shows everything unconditionally. > Proposal: a lightweight `show-if`/`depends` hint (field = value) driving > visibility/enablement, keeping the server as source of truth and > avoiding custom JS for the common case. same like above, for now making them optional with a respective placeholder text is good enough for starters; can be checked out and, if decided worthwhile, expanded later; nothing in the current design blocks us from doing so. > > P4 -- Client-side validation from format/pattern beyond `multiline`. > Only the `multiline` format is mapped; string `pattern`/`format` > (ip-address, and driver-specific formats like an ldev_range "256-511" > or colon-hex) fall back to a plain textfield, so the user only learns > of a bad value on submit. Proposal: map `pattern` -> ExtJS vtype/regex > and reuse existing PVE formats (ip-address, etc.). Integer > minimum/maximum already flow through -- thanks for that. More formats and mapping them to validators certainly makes sense in the long run; some common ones might be even get added initially or in the first polishing rounds; but the current design is not limiting us from expanding here, and the main important thing is to get fundamentals correct for now. > P5 -- Distinct enum display labels. > comboItems currently map [value, value], so operators see raw tokens > (e.g. "ops-center-cm") rather than a human label ("Ops Center > Configuration Manager"). Proposal: allow a verbose-label map alongside > enum (e.g. an enum-descriptions list, or reuse verbose_description). same here. > > P6 -- A per-plugin onlineHelp/docs anchor. > Inbuilt dialogs carry a Help button to the docs; custom plugins have > nowhere to point operators. Proposal: honor an onlineHelp anchor in the > plugin metadata so the generic panel renders the standard Help button. We're a bit vary for generic links, but such a plugin needs to be actively set up; so I do not see any big reason against providing some basic links and or notes to the storage plugins docs; it can be marked as external link after all. > > I will run the series against pve-FCLUPlugin on our lab and follow up > with a Tested-by separately. Thanks for driving this -- it closes a > long-standing gap for third-party storage vendors. Might have just missed that, but do you got that Plugin code already available somewhere to check out?