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
