[pve-devel] [PATCH manager] ui: backup job overview: add filter field

[Thomas Lamprecht]

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.