From: Dominik Csapak <d.csapak@proxmox.com>
To: Thomas Ellmenreich <t.ellmenreich@proxmox.com>,
pve-devel@lists.proxmox.com
Subject: Re: [RFC cluster/manager 0/2] Configurable window titles for nodes
Date: Tue, 14 Jul 2026 08:51:23 +0200 [thread overview]
Message-ID: <0ca38d86-a7c4-49ee-b3e8-a7b1dff72e72@proxmox.com> (raw)
In-Reply-To: <20260703115530.106413-1-t.ellmenreich@proxmox.com>
On 7/3/26 1:56 PM, Thomas Ellmenreich wrote:
> Configurable window titles for nodes
> ====================================
>
> Currently the window title is fixed to the following string:
>
> $nodename - Proxmox Virtual Environment
>
> This has become problematic for users with multiple clusters, each containing
> the same node name. To help distinguish between tabs, it has been requested [1]
> that the window title be made configurable with the fqdn as an option.
>
> [1] https://bugzilla.proxmox.com/show_bug.cgi?id=5475
>
> Current implementation
> ----------------------
>
> After considering the different options, I have deemed a server side
> implementation, through the datacenter.cfg, to be the better option.
> Specifically because of its durability across sessions and because it
> automatically configures the title for all users and all nodes across the
> cluster.
as we already discussed off-list, having this in the backend is fine for
me (and we can add a pure client override later too)
>
> The config file stores an enum string that will then be converted to a window
> title and inserted in the index.html.tpl file on every request.
>
> The current enum options are:
>
> - default - Displays the default '$nodename - Proxmox Virtual Environment' string
> if the config enum is not present
>
> - 'nodeandcluster' - Displays the nodename and then the clustername in the
> following style: '$nodename - $clustername'
>
> - 'fqdn' - Displays the current fqdn as returned by `PVE::Tools::get_fqdn()`
>
>
I mentioned it in one of the comments on the patch already but i think
we should add 'Proxmox Virtual Environment' (or Proxmox VE) to all titles.
just for completeness sake of what we discussed off-list some time ago,
we could think of having a template string for users to use
(e.g. like the backup comments) but it's probably overkill for the vast
majority of users...
Aside from my comments, patches LGTM
> Implementation options
> ----------------------
>
> The main question of this rfc is whether to implement this option as a
> client-side or server-side configuration. In my eyes, the pros and cons of each
> approach are the following.
>
> Storing config on clientside
> ----------------------------
> Pros:
> - Compared to a change in the datacenter.cfg, a session config does not
> have a lasting impact on nodes.
>
> - Every user can set the config themselves independent of the choices of
> the admin.
> Cons:
> - Every user is forced to change it themselves, there is no way to change
> the window title for all users
>
> - The title has to be changed for every single Node, even for a single
> User there is no way to change all nodes to a specific window title
> schema.
>
> - Configuration is not durable, meaning that it has to be set again after
> each Localstorage clear.
>
> Storing config in datacenter.cfg
> --------------------------------
>
> Pros:
> - The config is set once per cluster and will then be applied to every
> Node automatically.
>
> - Is persistent across sessions, and for all users, meaning it never has
> to be set again.
>
> Cons:
> - Since it is a change in the Datacenter config the change is more
> persistent
>
> - Users can not customize the window title themselves.
>
> - Only an Admin can change the configuration.
>
> Conclusion
> ----------
>
> I would appreciate feedback on both the approach and the configuration
> options. Are there any reasons for one or the other that I may have overlooked?
> Are there any other types of window title that we and the community would
> appreciate?
>
> Additional note
> ---------------
>
> If proper cross-node user settings are implemented in the future, this topic
> could be revisited, as some of the disadvantages of having a user-defined
> configuration would disappear.
>
>
> pve-manager:
>
> Thomas Ellmenreich (1):
> fix #5475: configurable window title
>
> PVE/Service/pveproxy.pm | 21 +++++++++++++++++++++
> www/index.html.tpl | 2 +-
> www/manager6/Utils.js | 11 +++++++++++
> www/manager6/dc/OptionView.js | 6 ++++++
> 4 files changed, 39 insertions(+), 1 deletion(-)
>
>
> pve-cluster:
>
> Thomas Ellmenreich (1):
> fix #5475: configurable window title
>
> src/PVE/DataCenterConfig.pm | 7 +++++++
> 1 file changed, 7 insertions(+)
>
>
> Summary over all repositories:
> 5 files changed, 46 insertions(+), 1 deletions(-)
>
prev parent reply other threads:[~2026-07-14 6:51 UTC|newest]
Thread overview: 6+ messages / expand[flat|nested] mbox.gz Atom feed top
2026-07-03 11:55 [RFC cluster/manager 0/2] Configurable window titles for nodes Thomas Ellmenreich
2026-07-03 11:55 ` [PATCH manager 1/2] fix #5475: configurable window title Thomas Ellmenreich
2026-07-14 6:47 ` Dominik Csapak
2026-07-03 11:55 ` [PATCH cluster 2/2] " Thomas Ellmenreich
2026-07-14 6:43 ` Dominik Csapak
2026-07-14 6:51 ` Dominik Csapak [this message]
Reply instructions:
You may reply publicly to this message via plain-text email
using any one of the following methods:
* Save the following mbox file, import it into your mail client,
and reply-to-all from there: mbox
Avoid top-posting and favor interleaved quoting:
https://en.wikipedia.org/wiki/Posting_style#Interleaved_style
* Reply using the --to, --cc, and --in-reply-to
switches of git-send-email(1):
git send-email \
--in-reply-to=0ca38d86-a7c4-49ee-b3e8-a7b1dff72e72@proxmox.com \
--to=d.csapak@proxmox.com \
--cc=pve-devel@lists.proxmox.com \
--cc=t.ellmenreich@proxmox.com \
/path/to/YOUR_REPLY
https://kernel.org/pub/software/scm/git/docs/git-send-email.html
* If your mail client supports setting the In-Reply-To header
via mailto: links, try the mailto: link
Be sure your reply has a Subject: header at the top and a blank line
before the message body.
This is a public inbox, see mirroring instructions
for how to clone and mirror all data and code used for this inbox