public inbox for pve-devel@lists.proxmox.com
 help / color / mirror / Atom feed
From: Thomas Lamprecht <t.lamprecht@proxmox.com>
To: Proxmox VE development discussion <pve-devel@lists.proxmox.com>,
	Dominik Csapak <d.csapak@proxmox.com>,
	Aaron Lauterer <a.lauterer@proxmox.com>
Subject: Re: [pve-devel] [PATCH manager] ui: backup job overview: add filter field
Date: Fri, 20 Sep 2024 10:29:12 +0200	[thread overview]
Message-ID: <0507ee35-f4b3-4785-a87a-ef973b675774@proxmox.com> (raw)
In-Reply-To: <6b1e39b7-3bab-413e-b018-b45d741e761e@proxmox.com>

Am 20/09/2024 um 08:09 schrieb Dominik Csapak:
>> For example, all VMIDs on a node. all VMIDs except the selected. VMIDs in resource pools, ...
> Fair, as that would "really" fix the bug. Just for the record, I did decide
> for a 'front-end' only approach because,
> 
> * less api calls/parameters to maintain
> * it probably solves most use cases (and searching inside pools/etc. could also be done here)
> 
> If we'd want to have a more comprehensive vmid <-> backup job lookup,
> i'd probably put it into the VM backup panel itself, or maybe as an addition to this filter
> as an explicit way to search for a vmid
> 
> no hard feelings either way though 🙂

FWIW, with the general job system it could be also an option to make a
generic job filter API where each job plugin can implement a method to
decide what/how to search for.

That way we could also create a "show backup jobs that guest is included
in" at the virtual guest's backup panel, or even a notice that it isn't
included in any (could be also done as a separate guest "health check"
window to avoid the cost of querying this every time the guest is visited
in the UI).

Anyhow, as while I understand why you went for this approach, it surely is
simpler and quicker to implement, I think that users could be confused by
not seeing a job for a VMID because it's not explicitly listed.
Especially once we get a tag-based selection, which would be great to have
soonish, I think that manual VMID selection will become less popular that
it is now already, as it's easier to re-use existing groupings compared to
having to update jobs on every guest creation/destruction.

One possibility could be to add this without VMIDs for now, albeit that's
naturally not ideal as the prime use case is checking in which job, if at
all, a VMID is included.

In summary, I think it's better to go for a "complete" solution here, even
if it means that we have to add some new API endpoints, if an evaluation
shows that the generic job-filter API is feasible, adding that endpoint
might give us a quite good ROI there though. If it doesn't seems to be
easily possible we still could go for a purely frontend based solution.


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

      parent reply	other threads:[~2024-09-20  8:29 UTC|newest]

Thread overview: 5+ messages / expand[flat|nested]  mbox.gz  Atom feed  top
2024-09-19 14:30 Dominik Csapak
2024-09-19 15:36 ` Aaron Lauterer
2024-09-20  6:09   ` Dominik Csapak
2024-09-20  7:22     ` Aaron Lauterer
2024-09-20  8:29     ` Thomas Lamprecht [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=0507ee35-f4b3-4785-a87a-ef973b675774@proxmox.com \
    --to=t.lamprecht@proxmox.com \
    --cc=a.lauterer@proxmox.com \
    --cc=d.csapak@proxmox.com \
    --cc=pve-devel@lists.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
Service provided by Proxmox Server Solutions GmbH | Privacy | Legal