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

[Ciro Iriarte <cyruspy@gmail.com>]

Hi Max, list,

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?
  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.

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.

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.

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.

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).

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.

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.

Thanks,
Ciro