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

[Ciro Iriarte <cyruspy@gmail.com>]

Hi Thomas,

On P1: agreed, and the Rust UI framework settles it. If index.html.tpl
injection is going away, a blessed JS override path would only be a dead
end I'd have to migrate off later, so I'd rather it not exist.

The part I'd still like to see land eventually is the backend method you
sketched -- a plugin-provided live verification the UI can call. That
covers my actual use cases (credential and endpoint validation, and
eventually populating pool IDs from the array) without any client-side
plugin code. I'm not asking for it in this series; I'd just like it kept
on the map, and I'm happy to be a test case when you get to it. An array
with a REST control plane is a reasonable worst case, since a credential
check is a network round trip that can take seconds.

Meanwhile I've implemented check_connection() in my plugin -- it connects
to the management endpoint and reaches the pool, so an unreachable array
now reports as offline rather than silently passing. on_add_hook() already
did the same probe at add time.

On the deferred items, I'd rather send patches than keep asking. Starting
with P6 (the docs link) since it's the smallest and has no schema
semantics to bikeshed -- an external-marked link per plugin, as you
described. If that shape works, P5 (a human label alongside enum values,
so operators see "Ops Center Configuration Manager" instead of
"ops-center-cm") would follow.

On P4 I'd narrow what I originally asked for. Max is right that
translating arbitrary Perl regex to ECMAScript isn't worth the risk, so
not that: just a lookup table mapping the named formats that already
exist in JSONSchema.pm -- ip, ipv4, ipv6 and similar -- to the vtypes
that already exist in the widget toolkit. Driver-specific formats stay
server-side. That makes it a table rather than a translation problem.

I'll hold all three until the base series lands, unless you'd rather see
them on top of it -- no point creating rebase churn while v2 is in review.
Nothing from me on P2/P3; the default layout groundwork should come first.

The plugin code:

  https://github.com/ciroiriarte/pve-FCLUPlugin

That's a vendor-neutral framework (generic core plus per-vendor drivers);
the Hitachi VSP driver is the reference implementation and the only one
live-validated so far, against a VSP E590H. The index.html.tpl injection
I mentioned is in there, so it also serves as a worked example of the
workaround this series retires.

Thanks,
Ciro