Re: [PATCH 0/7] client: add scheduled backup jobs

[Thomas Lamprecht <t.lamprecht@proxmox.com>]

Am 22.10.26 um 14:58 schrieb Christian Ebner:
> While skimming trough the patches a few ideas for potential improvements
> came to mind.

Thanks for your input, in general I'd try to not add too much scope creep
here, at least not for anything that can't be still (easily) added later.

> * Allowing to clone an already existing backup job: This would help to
> ease setup for multiple jobs with recurring patterns, e.g. only differing
> in namespace and backup specs.

potentially for the future, for now it's copying a few lines of text, not
the best UI/UX but at least a narrow scoped edited in a single config file.

> * Adding a connection test for a configured job: It is currently possible
> to setup a job with incorrect connection information for the PBS. I think
> it would be nice to have a command to perform a basic connection test
> without having to actually perform a backup run right away.

A `job run <id> --dry-run` basically does that (and a bit more). But that
might be actually nice in general to have independent of jobs but with an
optional job argument to take the repo args from there, or one for generic
case and the dry-run for jobs.

> * Splitting of the target config from the job config: It might make sense
> to have the target configurable independent of the job. And make it
> reusable for all the client commands not just the jobs itself. Although
> not so sure about this part, having all the config in the same place has
> advantages as well, and there will mostly be only a single target.

Might be convenient, but adds also complexity by adding another target
selection angle to existing repo as single string and atoms (and mix of
both).  OTOH, if we call it remote it would reuse a concept of what we got
on servers.

But, we would not need a new config file in any case, as such
targets/remotes/... can be their own section type. That makes updating the
config in a consistent and atomic manner also much (!) easier than having to
synchronize/lock multiple files. So I'd prefer a single config file, and as
mentioned, not a must to decide if we want this now or not, can be easily
added later.