all lists on lists.proxmox.com
 help / color / mirror / Atom feed
From: Dominik Csapak <d.csapak@proxmox.com>
To: Thomas Lamprecht <t.lamprecht@proxmox.com>,
	Proxmox Datacenter Manager development discussion
	<pdm-devel@lists.proxmox.com>
Subject: Re: [pdm-devel] [PATCH datacenter-manager 1/5] server: add an optional 'web-url' property for remotes
Date: Thu, 23 Jan 2025 14:31:41 +0100	[thread overview]
Message-ID: <582a0262-fa74-418d-ab09-b4e475bc7b82@proxmox.com> (raw)
In-Reply-To: <70921104-d224-4f16-ad40-4fc6aa9e90a5@proxmox.com>

On 1/23/25 09:48, Thomas Lamprecht wrote:
> Am 16.01.25 um 09:04 schrieb Dominik Csapak:
>> On 1/15/25 16:12, Thomas Lamprecht wrote:
>>> Am 10.01.25 um 11:21 schrieb Dominik Csapak:
>>>> this contains two optional values to generate a URL for the UI:
>>>> * per_node_template: a 'per node' template to generate an url, used for
>>>>     all places where we have node information. If not set we use the
>>>>     base_url as fallback to generate the url.
>>>>
>>>> * base_url: An URL for reaching the remote. This is e.g. useful if there
>>>>     is some reverse proxy or similar between the users browser and the
>>>>     remote.
>>>
>>> Why two, and not just one? And why was this already applied without
>>> any comment/review from people in the discussion of that feature?
>>
>> while I started out with that, I quickly noticed that in some places/situations we don't
>> have *any* information about the nodes at all, so we always have to have
>> some general base url we can fall back to.
>>
>> (i tried to convey that, but just realized that it was only in the cover letter,
>> should have said it in the commit message too, mea culpa)
> 
> Already talked off-list, but for that we want to add a cache with current
> online nodes where we then could select the first available one with stable
> sorting for some determinism in such a case.
> 
>>
>> we could still have a radio button/checkbox but we always have to have the
>> general url field, and simply turning on and off a single field is more
>> clutter than the current solution.
>>
>> (I'm fine with doing either though if you find that better)
>>
>> Of course, if we decide to implement more functions/features/options here that
>> require more/different inputs, some kind of selection for that would be
>> necessary.
> 
> Can we for now drop the templating and rework this to a single, fixed
> URL? That already helps in a lot of use cases, be it for when the UI is
> only accessible through a reverse proxy from the end user POV or even just
> a different domain for external access compared to how PDM talks with a
> node, as then one can just use a designated node's URL, while that's not
> perfect in case of that node being down, but when not it might be slightly
> nicer than different node URLs as one does not need to login so often.
> 
> With that I could cut a release soonish, we can then improve on this in
> the future.
> When we (re-)add templating and having the node map/status cache, it might
> be even nicer UX to always go through the first available node, even if that
> isn't the node the resource resides on – that would reduce needs for logins,
> i.e. when opening the UI for different guests on different nodes but on the
> same cluster, and also have slightly better caching behavior when loading
> the web UI code and assets. Allowing the PDM user to configure a priority
> order for nodes could then make it really flexible enough; but just some
> thought, not relevant for just now.
> 

Makes sense to me, so i sent a patch that removes it from the config for now:

https://lore.proxmox.com/pdm-devel/20250123132754.3271555-1-d.csapak@proxmox.com/

we can discuss how we want to handle that when we have the cache

> 
>>> The unrelated fixes would be also nice as separate patches, or at
>>> least upfront – as quite often stated already to all devs..
>>
>> true, but to be fair, the UI cleanups were 'upfront' of the other UI patches,
>> just not before the server patch, so they could have been applied either way.
> 
> Hmm, ok, while I'd still slightly prefer that (unrelated) clean-ups/fixes
> happen in a separate series or "fully" upfront, your way here is manageable
> too.

It's not a problem, I'll try to send such cleanups as separate series in the future if possible.
If another series depends on them, I'll add a note in the cover-letter (or similar).


_______________________________________________
pdm-devel mailing list
pdm-devel@lists.proxmox.com
https://lists.proxmox.com/cgi-bin/mailman/listinfo/pdm-devel

  reply	other threads:[~2025-01-23 13:31 UTC|newest]

Thread overview: 15+ messages / expand[flat|nested]  mbox.gz  Atom feed  top
2025-01-10 10:21 [pdm-devel] [PATCH yew-comp/datacenter-manager] make ui url generation configurable Dominik Csapak
2025-01-10 10:21 ` [pdm-devel] [PATCH yew-comp 1/1] form: add helpers for property strings Dominik Csapak
2025-01-10 10:21 ` [pdm-devel] [PATCH datacenter-manager 1/5] server: add an optional 'web-url' property for remotes Dominik Csapak
2025-01-15 15:12   ` Thomas Lamprecht
2025-01-16  8:04     ` Dominik Csapak
2025-01-23  8:48       ` Thomas Lamprecht
2025-01-23 13:31         ` Dominik Csapak [this message]
2025-01-10 10:21 ` [pdm-devel] [PATCH datacenter-manager 2/5] ui: remote edit: add missing key for displayfield Dominik Csapak
2025-01-10 10:21 ` [pdm-devel] [PATCH datacenter-manager 3/5] ui: remote edit: rename 'Nodes' to 'Endpoints' Dominik Csapak
2025-01-10 10:21 ` [pdm-devel] [PATCH datacenter-manager 4/5] ui: generate URLs with the option 'web-url' property Dominik Csapak
2025-01-10 10:21 ` [pdm-devel] [PATCH datacenter-manager 5/5] ui: remote edit: add 'web-url' options to the edit panel Dominik Csapak
2025-01-15 15:27   ` Thomas Lamprecht
2025-01-15 17:40     ` Dietmar Maurer
2025-01-13 14:33 ` [pdm-devel] [PATCH yew-comp/datacenter-manager] make ui url generation configurable Dominik Csapak
2025-01-15 13:12 ` [pdm-devel] applied: " Dietmar Maurer

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=582a0262-fa74-418d-ab09-b4e475bc7b82@proxmox.com \
    --to=d.csapak@proxmox.com \
    --cc=pdm-devel@lists.proxmox.com \
    --cc=t.lamprecht@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.
Service provided by Proxmox Server Solutions GmbH | Privacy | Legal