TrueNAS Storage Plugin

[Lorne Guse]

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