--- Begin Message ---
Apparently I missed the response to my last message. I intend to start
development on a pure TrueNAS storage plugin next week. I believe TrueNAS API
now has all the functionality needed to remove the need for ssh+root.
I'm going to be starting by mapping TrueNAS API methods to functions in
Plugin.pm, ZFSPoolPlugin.pm, and ZFSPlugin.pm.
I don't know who Roland is but any collaboration would be welcome.
> Lorne Guse via pve-devel <pve-devel at
> lists.proxmox.com<https://lists.proxmox.com/cgi-bin/mailman/listinfo/pve-devel>>
> hat am 13.05.2025 07:34 CEST geschrieben:
> I'm working on an update to https://github.com/TheGrandWazoo/freenas-proxmox
>
> My repo can be found here: https://github.com/boomshankerx/proxmox-truenas
>
> I'm considering writing a pure TrueNAS plugin to fully utilize their
> WebSocket API. I think
>
> I have a reasonable grasp on the existing storage plugins for ZFS over ISCSI
> however I'm not sure how to go about developing the UI component for a brand
> new plugin.
>
> The exiting plugins above inject some UI code via patch to accommodate some
> extra UI components. I imagine that this would be the case if I were to build
> a TrueNAS plugin from the ground up.
>
> I'd like some suggestions if there are any to give.
the rough plan (as previously discussed on this list, CCing Roland who might be
interested as well)
would be for the plugin to provide a "UI schema", and the UI code to derive a
basic form for adding
and editing the storage configuration based on that.
we are basically waiting for some third-party plugin developer to drive this
feature together with
us - if you want to step up to do that it would be great!
a rough sketch:
- plugin gets a new property defining how each of its options should be
presented on the UI
- an endpoint is added that returns the existing storage types + their schema
- JS code gets written that calls that endpoint and generates the 'add' and
'edit' windows
what's needed from the plugin dev side is mainly feedback on how the schema
could/should
look like, what kind of control would be desirable, and of course, validation
of the
implementation once it exists.
what we definitely don't want is to provide some sort of hookpoint for
arbitrary JS code,
that is far too brittle.
hope this helps,
Fabian
--- End Message ---
_______________________________________________
pve-devel mailing list
pve-devel@lists.proxmox.com
https://lists.proxmox.com/cgi-bin/mailman/listinfo/pve-devel
