convert maxfiles to prune_backups when reading the storage configuration

If there are already prune options configured, simply delete the maxfiles
setting. Having set both is invalid from vzdump's perspective anyways, and any
backup job on such a storage failed, meaning a user would've noticed.

If there are no prune options, translate the maxfiles value to keep-last,
except for maxfiles being zero (=unlimited), in which case we use keep-all.

If both are not set, don't set anything, so:
1. Storages don't suddenly have retention options set.
2. People relying on vzdump defaults can still use those.

Signed-off-by: Fabian Ebner <f.ebner@proxmox.com>

diff --git a/PVE/Storage.pm b/PVE/Storage.pm
index 7314085ef1da1b73902b3b811f8106094039e10c..8d904d74903e8af2d3780d24e6949c8b63e2ccf9 100755 (executable)
--- a/PVE/Storage.pm
+++ b/PVE/Storage.pm
@@ -129,6 +129,28 @@ sub lock_storage_config {
     }
 }
 
+# FIXME remove maxfiles for PVE 7.0
+my $convert_maxfiles_to_prune_backups = sub {
+    my ($scfg) = @_;
+
+    return if !$scfg;
+
+    my $maxfiles = delete $scfg->{maxfiles};
+
+    if (!defined($scfg->{'prune-backups'}) && defined($maxfiles)) {
+       my $prune_backups;
+       if ($maxfiles) {
+           $prune_backups = { 'keep-last' => $maxfiles };
+       } else { # maxfiles 0 means no limit
+           $prune_backups = { 'keep-all' => 1 };
+       }
+       $scfg->{'prune-backups'} = PVE::JSONSchema::print_property_string(
+           $prune_backups,
+           'prune-backups'
+       );
+    }
+};
+
 sub storage_config {
     my ($cfg, $storeid, $noerr) = @_;
 
@@ -138,6 +160,8 @@ sub storage_config {
 
     die "storage '$storeid' does not exist\n" if (!$noerr && !$scfg);
 
+    $convert_maxfiles_to_prune_backups->($scfg);
+
     return $scfg;
 }