we may want to even do this only once, before the loop, but for now
this is basically the same as it was previously but avoids the need
for every (future) plugin to do this manually; which is just the
wrong place.
Signed-off-by: Thomas Lamprecht <t.lamprecht@proxmox.com>
Also generalizes the way vzdump property strings are handled for jobs.
Something similar could be done in VZDump.pm, but there the maxfiles
and prune-backups settings are currently coupled, so a dedicated
parse_performance() is used instead. Can be changed once maxfiles is
dropped.
Signed-off-by: Fiona Ebner <f.ebner@proxmox.com>
like systemd-timers 'persistent'. so that the user can configure it to not be
run after powering up when it was previously missed
this reverses the default behaviour to not run missed jobs after pvescheduler
was started, since most of the time that's not the desired behaviour
since we don't use it for updated schedules anymore, rename
'updated_job_schedule' to 'update_last_runtime'
Signed-off-by: Dominik Csapak <d.csapak@proxmox.com>
Reviewed-by: Fabian Ebner <f.ebner@proxmox.com>
when we parse the config, we get the 'prune-backup' decoded, but the
api call we use wants it as a property string, so encode it here again
this fixes having jobs with prune options
Signed-off-by: Dominik Csapak <d.csapak@proxmox.com>
we want to write it out to the config as propertyString,
but want it as object in the api (for compatiblity)
Signed-off-by: Dominik Csapak <d.csapak@proxmox.com>
this adds a SectionConfig handling for jobs (only 'vzdump' for now) that
represents a job that will be handled by pvescheduler and a basic
'job-state' handling for reading/writing state json files
this has some intersections with pvesrs state handling, but does not
use a single state file for all jobs, but seperate ones, like we
do it in the backup-server.
Signed-off-by: Dominik Csapak <d.csapak@proxmox.com>
