for backwards compatibility. Otherwise, e.g. listing backup jobs with
pvesh get /cluster/backup is broken. And suddenly not having the
property anymore would be a breaking API change.
Signed-off-by: Fiona Ebner <f.eb...@proxmox.com>
---
I didn't see any other places that rely on the $job->{id} to be set.
The other backup-related API calls and Jobs.pm iterate or check the
ids from the section config's $parsed->{ids}. Scheduler doesn't need
either AFAICT.
@Dominik: I guess you need to adapt the (not-yet-applied) realm sync
jobs API too now that the id is not auto-injected.
PVE/API2/Backup.pm | 11 ++++++++++-
1 file changed, 10 insertions(+), 1 deletion(-)
diff --git a/PVE/API2/Backup.pm b/PVE/API2/Backup.pm
index b6f5916d..3a079874 100644
--- a/PVE/API2/Backup.pm
+++ b/PVE/API2/Backup.pm
@@ -130,6 +130,10 @@ __PACKAGE__->register_method({
$job->{'next-run'} = $next_run if defined($next_run);
}
+ # FIXME remove in PVE 8.0?
+ # backwards compat: before moving the job registry to pve-common,
id was auto-injected
+ $job->{id} = $jobid;
+
push @$res, $job;
}
@@ -273,7 +277,12 @@ __PACKAGE__->register_method({
my $jobs_data = cfs_read_file('jobs.cfg');
my $job = $jobs_data->{ids}->{$param->{id}};
- return $job if $job && $job->{type} eq 'vzdump';
+ if ($job && $job->{type} eq 'vzdump') {
+ # FIXME remove in PVE 8.0?
+ # backwards compat: before moving the job registry to pve-common,
id was auto-injected
+ $job->{id} = $param->{id};
+ return $job;
+ }
raise_param_exc({ id => "No such job '$param->{id}'" });
--
2.30.2
_______________________________________________
pve-devel mailing list
pve-devel@lists.proxmox.com
https://lists.proxmox.com/cgi-bin/mailman/listinfo/pve-devel
