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 an external index of several public inboxes,
see mirroring instructions on how to clone and mirror
all data and code used by this external index.