mcst-linux-kernel/patches-2024.06.26/lxd-3.0.0/0016-Fix-lxd-init-failing-t...

44 lines
1.7 KiB
Diff

From de5dc34bc55df6f0ad63c3b720ac340c4042ea67 Mon Sep 17 00:00:00 2001
From: Free Ekanayaka <free.ekanayaka@canonical.com>
Date: Wed, 4 Apr 2018 08:04:59 +0000
Subject: Fix lxd init failing to join a cluster in interactive mode with an
existing zfs dataset
AFAIU, we were passing to POST /1.0/storage-pools some internal config keys that
are generated by LXD when it handles the request, and shouldn't be included in
the request payload.
For some reason doing that didn't break in the case where you were creating a
new zfs pool (setting "source" to a block device), but it does break when
setting "source" to an existing zfs pool name.
I manually tested the fix to confirm it works, since at the moment we don't have
a way to run lxd init interactively in integration tests (the main issue is how
to ask for the trust password).
The lxd init --preseed case was not affected by this bug, as long as you avoid
including those internal config keys in your YAML.
Closes #4404.
Signed-off-by: Free Ekanayaka <free.ekanayaka@canonical.com>
---
lxd/main_init_interactive.go | 4 ++++
1 file changed, 4 insertions(+)
diff --git a/lxd/main_init_interactive.go b/lxd/main_init_interactive.go
index 89863201..240acf0d 100644
--- a/lxd/main_init_interactive.go
+++ b/lxd/main_init_interactive.go
@@ -189,6 +189,10 @@ func (c *cmdInit) askClustering(config *initData, d lxd.ContainerServer) error {
Name: pool.Name,
}
+ // Delete config keys that are automatically populated by LXD
+ delete(newPool.Config, "volatile.initial_source")
+ delete(newPool.Config, "zfs.pool_name")
+
// Only ask for the node-specific "source" key if it's defined in the target node
if pool.Config["source"] != "" {
// Dummy validator for allowing empty strings