[pbs-devel] [PATCH v3 proxmox-backup] ui: warn of missing gc-schedule, prune/verify jobs

[Christian Ebner]

> On 06.12.2023 15:09 CET Fabian Grünbichler <f.gruenbichler at proxmox.com> wrote:
> 
> 
> for all of them there are possible reasons for not having them set up:
> - verify: I trust my storage to protect me against bit rot, and I don't want to incur the performance penalty of doing a full verification just to ensure logical consistency
> - prune: I only do client-side pruning
> - prune+GC: this is an append-only backup storage, I never want to remove data

True and I am aware of that. That is why I opted for a warning rather than showing these as errors. But of course an information might be even more fitting here. But I would like to not hide the not configured states to much, as the main point of adding these, is to inform the user that he might be missing something, after all. Maybe I should also add a tool tip to show some explanation for the warning/info when hovered?

> 
> all of those could be improved of course (logical-verification as a verify mode or new job type, changing the warning to information if a prune action was done recently, allowing an explicit "append-only" flag that actually disallows pruning, ..)
> 
> all of them except for GC also don't take namespaces into account, but that might be harder to get right.

Yes, these only cover if the datastore as a whole currently. Another reason why the green check mark might not be so ideal after all. I will have a look if I might get the namespace information as well without having to perform to much API calls here, as then this status update might produce to much calls for users with many namespaces. Also, I am not sure that this information can be compactly displayed except maybe a "there are namespaces without jobs configured".

> 
> there's another source of confusion if I am an unprivileged user - I might not "see" the jobs that are defined, and get a warning as a result, even though everything is okay. that last one *could* be tackled by leaking the count, even if not leaking the details, but I am not sure if we want to do that ;) for GC at least we could differentiate based on status code and make the user aware that unknown is for lack of privs.

Hmm, good point. Maybe I should not show the state information (and fetch via the API) for that job at all if the user has no privileges? Will have a look if I can exclude these.

> 
> I'd also differentiate between "unknown because no request made/no response retrieved yet" and "unknown because request failed" - the latter case should be a "warning" as well (and ideally contain the error at least as tool tip?), and not "missing", except if we can match the failure to missing privileges..

Yes, will have a look on improving this as well. Showing the error message might be a bit more messy, but the suggested tool tip could be a viable option.

Thank you for the feedback!

Cheers,
Chris