From mboxrd@z Thu Jan  1 00:00:00 1970
Return-Path: <pve-devel-bounces@lists.proxmox.com>
Received: from firstgate.proxmox.com (firstgate.proxmox.com [212.224.123.68])
	by lore.proxmox.com (Postfix) with ESMTPS id 1AACE1FF16B
	for <inbox@lore.proxmox.com>; Thu,  3 Apr 2025 14:34:34 +0200 (CEST)
Received: from firstgate.proxmox.com (localhost [127.0.0.1])
	by firstgate.proxmox.com (Proxmox) with ESMTP id 459952F4;
	Thu,  3 Apr 2025 14:31:53 +0200 (CEST)
From: Wolfgang Bumiller <w.bumiller@proxmox.com>
To: pve-devel@lists.proxmox.com
Date: Thu,  3 Apr 2025 14:30:40 +0200
Message-Id: <20250403123118.264974-1-w.bumiller@proxmox.com>
X-Mailer: git-send-email 2.39.5
MIME-Version: 1.0
X-SPAM-LEVEL: Spam detection results:  0
 AWL 0.080 Adjusted score from AWL reputation of From: address
 BAYES_00                 -1.9 Bayes spam probability is 0 to 1%
 DMARC_MISSING             0.1 Missing DMARC policy
 KAM_DMARC_STATUS 0.01 Test Rule for DKIM or SPF Failure with Strict Alignment
 SPF_HELO_NONE           0.001 SPF: HELO does not publish an SPF Record
 SPF_PASS               -0.001 SPF: sender matches SPF record
Subject: [pve-devel] [PATCH v8 storage 0/9] backup provider API
X-BeenThere: pve-devel@lists.proxmox.com
X-Mailman-Version: 2.1.29
Precedence: list
List-Id: Proxmox VE development discussion <pve-devel.lists.proxmox.com>
List-Unsubscribe: <https://lists.proxmox.com/cgi-bin/mailman/options/pve-devel>, 
 <mailto:pve-devel-request@lists.proxmox.com?subject=unsubscribe>
List-Archive: <http://lists.proxmox.com/pipermail/pve-devel/>
List-Post: <mailto:pve-devel@lists.proxmox.com>
List-Help: <mailto:pve-devel-request@lists.proxmox.com?subject=help>
List-Subscribe: <https://lists.proxmox.com/cgi-bin/mailman/listinfo/pve-devel>, 
 <mailto:pve-devel-request@lists.proxmox.com?subject=subscribe>
Reply-To: Proxmox VE development discussion <pve-devel@lists.proxmox.com>
Content-Type: text/plain; charset="us-ascii"
Content-Transfer-Encoding: 7bit
Errors-To: pve-devel-bounces@lists.proxmox.com
Sender: "pve-devel" <pve-devel-bounces@lists.proxmox.com>

v7: https://lore.proxmox.com/pve-devel/20250401173435.221892-1-f.ebner@proxmox.com/

I picked this up since Fiona is currently not available.

This contains 1 "major" change (and incorporates some minor doc feedback
from Max (sans the `=head` rewrite, feel free to send follow-up patches
for this @Max).

The change is that instead of having a 

    sub backup_vm_available_bitmaps($self, $volumes)

which fills bitmap names into the passed-along $volumes array,
there is now a

    sub backup_vm_query_incremental($self, $volumes)

which should *return* a new hash (as modifying parameters is a bit
awkward if a plugin is not written in perl, eg. our rust perlmod...),
which instead of bitmap *names*, contains bitmap *modes* which are:

    - new: create a new bitmap, or *recreate* an existing one
    - use: use an existing bitmap, or create one if none exists

Bitmap names have two issues:
1. It is not clear if they are actually useful.
2. They do not provide a way to distinguish between the above modes.
   If the backup provider loses access to a drive which used a bitmap
   before, the only way to recreate it was to *rename* it, which meant
   keeping track of those names.

   So now the only thing we need to keep track of, which for some backup
   providers can *probably* happen without any extra state, is which
   drive a bitmap is relative to.
   Tracking names on the other hand is quite an awkward interface.

Changes in v8:
- storage: replace backup_vm_available_bitmaps() with backup_vm_query_incremental()
- qemu: add an explicit optional 'bitmap-mode' parameter to
  qmp_backup_access_setup()
- qemu-sever: adapt to the storage api change and pass the bitmap-mode
  to the qmp-backup-access-setup command
- storage: adapt directory example
- storage: change the previous-info file to be a json hash mapping disks
  to their last backups
- qemu-server: fix 'bwlimit'/'bwlimiit' typo
- qemu: fix a leak on error in `get_single_device_info()`

build order:
1. qemu
2. storage
3. a) qemu-server: depends on qemu + storage
   b) pve-container: depends on storage
4. manager: depends on qemu-server/container I guess


_______________________________________________
pve-devel mailing list
pve-devel@lists.proxmox.com
https://lists.proxmox.com/cgi-bin/mailman/listinfo/pve-devel