Re: [PATCH common/manager/proxmox-widget-toolkit/storage 00/13] GUI Support for Custom Storage Plugins

[Thomas Lamprecht <t.lamprecht@proxmox.com>]

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?