Re: [pve-devel] [RFC pve-storage, pve-manager master v1 00/12] GUI Support for Custom Storage Plugins

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

On Mon Sep 8, 2025 at 9:23 PM CEST, Thomas Lamprecht wrote:
> Am 08.09.25 um 20:01 schrieb Max R. Carrara:
> > GUI Support for Custom Storage Plugins
> > ======================================
> > 
> > tl;dr:
> > 
> > Add an API method to PVE::Storage::Plugin that returns the definition
> > for the form view of custom storage plugins. This definition is used by
> > the frontend to build the form view for creating / editing the storage
> > config entry of the plugin. The ultimate goal here is that custom
> > storage plugin devs don't have to (and also *must not*) ever touch
> > JavaScript to make their plugins show up in the GUI.
>
> Did not check the changes in full, but I see no mentioning of the ACME
> DNS plugins, which already provide such a mechanism, albeit a bit lower
> level with no real control how the fields get layouted. Did you check
> that out and maybe already re-used the underlying parts of the
> implementation but just not referenced it, or is this something
> completely new/custom?

This is something completely new, as the code regarding the ACME DNS
plugins isn't really adaptable / applicable in this case here.

When Aaron and I brainstormed the whole thing, he did mention that we
already do a somewhat similar thing with the ACME DNS plugins and
suggested that I might want to check that out first. Dominik then also
mentioned it, but suggested that I probably shouldn't implement it the
way we did for the ACME DNS plugins, so I decided to not look at that
code at all.

However, Dominik and I just went through the ACME GUI stuff for good
measure and found two main reasons why the functionality can't really be
reused:

1. The ACME DNS plugin [schema] is too simple and doesn't really
translate to storage plugins.

In particular, the [schema] is static, with all fields except one being
of type "string". Things like checkboxes and dynamic dropdown selection
boxes aren't really accounted for, since they're not needed.

2. The ACME DNS API [edit window] is designed for editing on the fly.

The entire [schema] is fetched at once from the backend. The window
remembers which DNS API the user selected and stores the KV-pairs in the
background. So when you switch back and forth between e.g. "Cloudflare
Managed DNS" and "Alibaba Cloud DNS", the values you entered are
retained.

If you then switch to an API without any fields in the schema, the
existing KV-pairs of other plugins are inserted into the fallback text
area. If you select an API with fields again, the content of the text
area is parsed back into the KV-pairs.

So, also not something that's really applicable / reusable for storage
plugins.

>
> Further, FWICT this seems to add some parallel infra and need of
> definitions, might we get away with "just" annotating the existing
> schemas a bit better, i.e. add the flags for signaling secrets and
> potentially some layout hints, as the core importance is to be able to
> input required data to configure a storage, not that it needs to look
> "perfect", at least not in the initial version of this implementation,
> as adding more features and complexer layouting later on, especially
> once we got feedback from integrators and see how they use it.

Maybe I should clarify that the core part of this RFC isn't really the
layouting: The form view schema allows devs to specify which columns are
used, and a column is just an object with an array of fields. The fields
are displayed in the order in which they appear in the column. That's
about as much layouting as one can do at the moment.

What's important are the definitions of the fields themselves. Each
field corresponds to a SectionConfig property of the storage plugin the
form is defined for.

To provide some additional context before I continue, my initial idea
was to *just* define what SectionConfig properties are shown in the UI
and have the rest be "inferred" in some way from the global set of
SectionConfig properties.

That quickly turned out to be a huge can of worms, raising a lot of
questions:

- Single Selection:

  * How would "string" type properties whose value is
    from a set of possible selection values be shown in the UI?

      Would need a hint that it's a "single-selection" field or
      something.

  * How would one tell the UI which possible selection values there are?

      Hard to do with just a hint / marker, as those selection values
      can be dynamic, e.g. the possible selections for the "pool" prop of
      the ZFSPoolPlugin are determined by listing which pools are
      available via the ZFS CLI.

- Multiple Selections:

  * Same as above, but with multiple possible selection values (usually
    properties that have a format whose name ends with "-list").

- Sensitive Properties:

  * How should sensitive properties be shown in the UI?

      We currently do not do that uniformly, e.g. the "Password" field
      of the ESXi importer always has `inputType: 'password'` whether
      you're creating or editing it, whereas the "Keyring" field of the
      RBD storage is displayed during creation but isn't shown nor
      editable when editing it (amongst other things).

The list goes on; I think you get the idea. :P

So, instead of making possibly restrictive design decisions for use
cases I'm not even aware of, I instead chose this "manual" way of
defining the form view, sidestepping all those questions.

*For now* this also seems to be the simpler, and more importantly, more
maintainable option, since things related to the UI aren't coupled to
the SectionConfig definitions (besides specifying what property a field
corresponds to). I think that this approach makes it overall easier for
third-party plugin devs to integrate their plugin into the GUI, and it's
something we could eventually also adopt for most of our own plugins.

> As it's much easier to see what's really required and what might be
> rather a (not much used) headache to maintain support for in ExtJS
> and a future Yew based UI. I.e., I'd be totally fine if the initial
> version would basically look like what the ACME DNS plugin UI does,
> focusing purely on required parameters, data types and validation
> over layout.

I totally get your point here, and the focus is on exactly
that—whether or not the columns are in the schema doesn't really make
any difference IMHO.

>
> Btw. this is partially related to [0] and I thought there was
> another issue tracking this, but couldn't find one from a quick search.

Ah, thanks for pointing me towards this; I'll assign it to myself if you
don't mind.

>
> [0]: https://bugzilla.proxmox.com/show_bug.cgi?id=3420

[schema]: /usr/share/proxmox-acme/dns-challenge-schema.json
[edit window]: https://git.proxmox.com/?p=proxmox-widget-toolkit.git;a=blob;f=src/window/ACMEPluginEdit.js;h=900923b98788a8d1e6fa3f1bc2004495ac297969;hb=refs/heads/master


_______________________________________________
pve-devel mailing list
pve-devel@lists.proxmox.com
https://lists.proxmox.com/cgi-bin/mailman/listinfo/pve-devel