[pbs-devel] [PATCH v4 proxmox-backup 00/10] add job based verify scheduling
Thomas Lamprecht
t.lamprecht at proxmox.com
Tue Oct 20 19:18:55 CEST 2020
On 20.10.20 11:10, Hannes Laimer wrote:
> Replaces the first implementation of scheduled verification with a new
> job-based version with additional options that may be specified through
> the web ui.
>
> Options available for verification jobs:
> * schedule when to run the job
> * set datastore on which the job should run
> * set a number of days after which a verification becomes "outdated"
> empty => verifications are valid forever
> * specify if already successfuly verified snapshots should be verified
> again even if they're not outdated(failed ones will always be done)
>
> v4:
> * squashed patches
> * rebased
> * no build-breaking patch
> * correct old config files in postinst
much nicer split and organization of the patch series and each commit builds
and tests successfully, great!
How those schedules and datastore stuff is organized in the GUI is still open,
but that should not be a blocker for this series, can be done afterwards -
Dominik and I had already some discussion about this.
@Dominik, would be good if we could hatch a more specific plan for this tomorrow.
There are two things which I find a bit "weird" or not ideal with the verification
schedule settings.
1. Why a "Verify Job ID" (possibly also s/Verify/Verification/)?
The user already has the comment fields for notes, and forcing them to give
each job a name makes no sense, IMO. I know that an ID is required for working
with each schedule, but that could be internal and automatically derived.
Either by choosing some random UUID assigned on add, similar to what we do in
PVE for backup jobs, or, alternatively join all relevant settings (datastore id,
schedule, days valid, ignore verified) and use that as ID (e.g., encoded or
md5sum'd) - this could even help to avoid that user specify the exact same job
multiple times.
However, the ID has to go IMO, this is not something a user will often specify
when interfacing with the PBS, like the Datstore id is, but a schedule which one
normally does not names. (naming is not only hard for Devs, it's also hard for
users)
2. documentation is missing
3. there was something besides that, but it's late and I'm really have to stop
working for today ^^
Anyway, it seems to work (from a few quick tests), I'd like to have a quick talk
with Dominik tomorrow (mostly about point 1. above) and then I'd apply this,
UX stuff can then be followed up.
thanks!
More information about the pbs-devel
mailing list