We opted for a simple copy of the legacy file to the new location,
since any other migration path would be too strenuous. The worst-case
scenario of failures with this approach is losing IPAM / MAC entries
that are created during the update window in the legacy files by nodes
that are not yet updated to the new version. Those can be fixed by
a simple start / stop of the affected VMs, triggering a rewrite of the
IPAM database.
Signed-off-by: Stefan Hanreich <s.hanre...@proxmox.com>
---
I took the liberty of already including a version guard, since we will
apply it directly before bumping. If that's a wrong assumption or if
the version number is wrong, please adapt it respectively.
debian/libpve-network-perl.postinst | 32 +++++++++++++++++++++++++++++
1 file changed, 32 insertions(+)
create mode 100644 debian/libpve-network-perl.postinst
diff --git a/debian/libpve-network-perl.postinst
b/debian/libpve-network-perl.postinst
new file mode 100644
index 0000000..733961b
--- /dev/null
+++ b/debian/libpve-network-perl.postinst
@@ -0,0 +1,32 @@
+#!/bin/sh
+
+set -e
+
+migrate_ipam_db() {
+ LEGACY_IPAM_DB_FILE="/etc/pve/priv/ipam.db"
+ IPAM_DB_FILE="/etc/pve/sdn/pve-ipam-state.json"
+
+ if test -f "$LEGACY_IPAM_DB_FILE" && test ! -f "$IPAM_DB_FILE"; then
+ cp $LEGACY_IPAM_DB_FILE $IPAM_DB_FILE
+ fi
+}
+
+migrate_mac_cache() {
+ LEGACY_MAC_DB_FILE="/etc/pve/priv/macs.db"
+ MAC_DB_FILE="/etc/pve/sdn/mac-cache.json"
+
+ if test -f "$LEGACY_MAC_DB_FILE" && test ! -f "$MAC_DB_FILE"; then
+ cp $LEGACY_MAC_DB_FILE $MAC_DB_FILE
+ fi
+}
+
+case "$1" in
+ configure)
+ if dpkg --compare-versions "$2" 'lt' '0.9.9'; then
+ migrate_ipam_db
+ migrate_mac_cache
+ fi
+ ;;
+esac
+
+exit 0
--
2.39.5
_______________________________________________
pve-devel mailing list
pve-devel@lists.proxmox.com
https://lists.proxmox.com/cgi-bin/mailman/listinfo/pve-devel
