Lxd.daemon starts too early in the latest lxd snap and fails to join the cluster

LXD
, ,
1

in the latest snap lxd daemon starts too early and then fails to connect to the cluster because it can not resolve its own name.

Feb 14 18:47:43 localhost.localdomain lxd.daemon[2936]: t=2022-02-14T18:47:43+0100 lvl=warn msg="AppArmor support has been disabled because of lack of kernel support"
Feb 14 18:47:43 localhost.localdomain lxd.daemon[2936]: t=2022-02-14T18:47:43+0100 lvl=warn msg=" - AppArmor support has been disabled, Disabled because of lack of kernel support"
Feb 14 18:47:43 localhost.localdomain lxd.daemon[2936]: t=2022-02-14T18:47:43+0100 lvl=warn msg=" - Couldn't find the CGroup blkio.weight, disk priority will be ignored"
Feb 14 18:47:43 localhost.localdomain lxd.daemon[2936]: t=2022-02-14T18:47:43+0100 lvl=eror msg="Invalid configuration key: Couldn't resolve \"lxd13\"" key=cluster.https_address
Feb 14 18:47:43 localhost.localdomain lxd.daemon[2936]: t=2022-02-14T18:47:43+0100 lvl=eror msg="Invalid configuration key: Couldn't resolve \"lxd13\"" key=core.https_address
Feb 14 18:47:43 localhost.localdomain lxd.daemon[2936]: t=2022-02-14T18:47:43+0100 lvl=eror msg="Invalid configuration key: Couldn't resolve \"lxd13\"" key=cluster.https_address
Feb 14 18:47:43 localhost.localdomain lxd.daemon[2936]: t=2022-02-14T18:47:43+0100 lvl=eror msg="Invalid configuration key: Couldn't resolve \"lxd13\"" key=core.https_address
Feb 14 18:47:43 localhost.localdomain lxd.daemon[2936]: t=2022-02-14T18:47:43+0100 lvl=eror msg="Invalid configuration key: Couldn't resolve \"lxd13\"" key=cluster.https_address
Feb 14 18:47:43 localhost.localdomain lxd.daemon[2936]: t=2022-02-14T18:47:43+0100 lvl=eror msg="Invalid configuration key: Couldn't resolve \"lxd13\"" key=core.https_address
Feb 14 18:47:43 localhost.localdomain lxd.daemon[2936]: t=2022-02-14T18:47:43+0100 lvl=eror msg="Invalid configuration key: Couldn't resolve \"lxd13\"" key=cluster.https_address
Feb 14 18:47:43 localhost.localdomain lxd.daemon[2936]: t=2022-02-14T18:47:43+0100 lvl=eror msg="Invalid configuration key: Couldn't resolve \"lxd13\"" key=core.https_address
Feb 14 18:47:43 localhost.localdomain lxd.daemon[2936]: t=2022-02-14T18:47:43+0100 lvl=eror msg="Invalid configuration key: Couldn't resolve \"lxd13\"" key=cluster.https_address
Feb 14 18:47:43 localhost.localdomain lxd.daemon[2936]: t=2022-02-14T18:47:43+0100 lvl=eror msg="Invalid configuration key: Couldn't resolve \"lxd13\"" key=core.https_address
Feb 14 18:47:43 localhost.localdomain lxd.daemon[2936]: t=2022-02-14T18:47:43+0100 lvl=warn msg="Dqlite: attempt 1: server 1: no known leader"
Feb 14 18:47:44 localhost.localdomain lxd.daemon[2936]: t=2022-02-14T18:47:44+0100 lvl=warn msg="Dqlite: attempt 2: server 1: no known leader"

I have cluster and core addresses set to hostnames, not sure if this is the right way to do it? I would rather not put an IP address in there in case I decide to renumber hosts later via DHCP. What is the recommended way to configure cluster and core address of a cluster member that has a potentially floating IP?

I have “fixed” this by overriding the After= in the systemd unit to say After=network-online.target, but would rather that to be fixed upstream if possible.

is this the correct place tor report lxd snap bugs?

2

A systemd override should be fine in this case.

We do not control the generated units at all unfortunately so not something we can tweak ourselves.

For clusters, I do tend to either use IP addresses or at least make sure they’re specified in /etc/hosts so that a DNS glitch doesn’t take everything down.

3

can yoiu please elaborate how can a DNS glitch take everything down? Once a node joins the raft, DNS is not used for anything, is it?

also, if you know, please share where does one file a bug against snap, I googled for half an hour and couldn’t find it.