From de5dc34bc55df6f0ad63c3b720ac340c4042ea67 Mon Sep 17 00:00:00 2001 From: Free Ekanayaka 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 --- 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