From mboxrd@z Thu Jan  1 00:00:00 1970
Return-Path: <pve-devel-bounces@lists.proxmox.com>
Received: from gate001.proxmox.com (gate001.proxmox.com [45.144.208.40])
	by lore.proxmox.com (Postfix) with ESMTPS id 7634D1FF0E1
	for <inbox@lore.proxmox.com>; Mon, 13 Jul 2026 15:02:12 +0200 (CEST)
Received: from gate001.proxmox.com (localhost.localdomain [127.0.0.1])
	by gate001.proxmox.com (Proxmox) with ESMTP id D1BA321438;
	Mon, 13 Jul 2026 15:02:11 +0200 (CEST)
Message-ID: <eec17f6f-3521-4368-9457-3ce89f6b7c3d@proxmox.com>
Date: Mon, 13 Jul 2026 15:01:35 +0200
MIME-Version: 1.0
User-Agent: Mozilla Thunderbird Beta
Subject: Re: Supported way to extend the PVE web UI for a third-party package?
To: Chiranth J S <Chiranth.JS@datacore.com>,
 "pve-devel@lists.proxmox.com" <pve-devel@lists.proxmox.com>
References: 
 <CH3PR11MB849513C3D52AC9211EA54B828AFA2@CH3PR11MB8495.namprd11.prod.outlook.com>
Content-Language: en-US
From: Dominik Csapak <d.csapak@proxmox.com>
In-Reply-To: 
 <CH3PR11MB849513C3D52AC9211EA54B828AFA2@CH3PR11MB8495.namprd11.prod.outlook.com>
Content-Type: text/plain; charset=UTF-8; format=flowed
Content-Transfer-Encoding: 8bit
X-Bm-Milter-Handled: 55990f41-d878-4baa-be0a-ee34c49e34d2
X-Bm-Transport-Timestamp: 1783947681023
X-SPAM-LEVEL: Spam detection results:  0
	AWL                     0.229 Adjusted score from AWL reputation of From:
 address
	DMARC_MISSING             0.1 Missing DMARC policy
	KAM_DMARC_STATUS         0.01 Test Rule for DKIM or SPF Failure with Strict
 Alignment (newer systems)
	POISEN_SPAM_PILL          0.1 Meta: its spam
	POISEN_SPAM_PILL_1        0.1 random spam to be learned in bayes
	POISEN_SPAM_PILL_3        0.1 random spam to be learned in bayes
	RCVD_IN_DNSWL_LOW        -0.7 Sender listed at https://www.dnswl.org/,
 low trust
	SPF_HELO_NONE           0.001 SPF: HELO does not publish an SPF Record
	SPF_PASS               -0.001 SPF: sender matches SPF record
Message-ID-Hash: IB3PNMDH4SYNIIDCES55PA7VTRGIFZBF
X-Message-ID-Hash: IB3PNMDH4SYNIIDCES55PA7VTRGIFZBF
X-MailFrom: d.csapak@proxmox.com
X-Mailman-Rule-Misses: dmarc-mitigation; no-senders; approved; loop;
 banned-address; emergency; member-moderation; nonmember-moderation;
 administrivia; implicit-dest; max-recipients; max-size; news-moderation;
 no-subject; digests; suspicious-header
CC: Vikash Ray <Vikash.Ray@datacore.com>,
 Prajwal Shetty <prajwal.shetty@datacore.com>
X-Mailman-Version: 3.3.10
Precedence: list
List-Id: Proxmox VE development discussion <pve-devel.lists.proxmox.com>
List-Help: <mailto:pve-devel-request@lists.proxmox.com?subject=help>
List-Owner: <mailto:pve-devel-owner@lists.proxmox.com>
List-Post: <mailto:pve-devel@lists.proxmox.com>
List-Subscribe: <mailto:pve-devel-join@lists.proxmox.com>
List-Unsubscribe: <mailto:pve-devel-leave@lists.proxmox.com>

On 7/13/26 1:59 PM, Chiranth J S wrote:
> Hello,

Hi,

> 
> I work at DataCore SANsymphony team. We ship a SANsymphony storage backend for PVE on the supported PVE::Storage::Plugin contract,  presenting vDisks over iSCSI. That side has worked well and is in production with customers.

Great to hear!

> 
> We also have a prototype that adds a native-feeling UI on top of it (a tab with vDisk aliases, snapshot/rollback, resize and performance). Since we couldn't find an official UI-extension hook, it currently works by patching two pve-manager files at install time — adding a <script> tag to index.html.tpl and a register_method for a /nodes/<node>/datacore/... route in PVE/API2/Nodes.pm — with a dpkg trigger to re-apply after upgrades.
> 
> We understand the long-standing guidance that features should be added "directly, no plugin," and we're weighing whether to productize this. Before we decide, two questions:
> 
> 
>    1.
> Is there any supported or planned mechanism to extend the PVE web UI (add a view/tab) or register a nodes/<node>/... API2 route from a third-party package — anything analogous to the storage plugin contract, but for the frontend?
>    2.
> If not, is in-place patching of index.html.tpl / Nodes.pm considered an acceptable approach (several community projects do this), or does it put a node in an unsupported state from your perspective? Is there a pattern you'd recommend instead?
> 
> 
> A clear "there's no supported hook, don't patch core files" is just as useful to us as a yes.
> Thanks for your time, and for the storage plugin API.
> 
> Best regards,
> Chiranth JS
> 
Currently there is no hook to extend the GUI or add any API calls.

There is ongoing work to expose a schema for custom storage plugins so
they can be added/edited/etc. via the GUI:

https://lore.proxmox.com/pve-devel/20260623143402.772452-1-m.carrara@proxmox.com/

However, this is still very much in progress. Feedback is welcome
though, the sooner we can gauge external needs and requirements,
the better.

I'm not sure what kind of integration you've built or are planning,
but as far as I know, there is no plan to allow external vendors
to add generic UI functionality or API calls.

Modifying the files we ship is always problematic: they will be
overwritten by a package update and depending on how the patching is 
done, it might break our UI and/or can cause support issues on our side.

So we'd strongly prefer that vendors do not modify the stock PVE files.

That said, if you've identified a place where PVE could benefit from
such a plugin/extension, please discuss (as concretely as possible) such
requirements here on the mailing list or via our bugtracker:
https://bugzilla.proxmox.com

We can't promise to implement anything specific, but understanding what
vendors might need or want can help us (and you) find a solution that
benefits both.

Hope this answers your questions, don't hesitate to follow up or open
bug reports and feature requests.

Best regards
Dominik