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
prev 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 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.