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

["Max R. Carrara" <m.carrara@proxmox.com>]

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