`lxd recover` does not restore profile configs

[simondeziel]

Just went through a lxd recover (see https://github.com/canonical/lxd/issues/14753) and the default profile obtained in the end lacked all the configs it initially had.

Initially, the default profile was created with:

lxc profile set default security.syscalls.deny="$(echo -e 'io_uring_setup\nio_uring_enter\nio_uring_register')"
lxc profile set default security.protection.delete=true
lxc profile set default security.syscalls.deny_compat=true
lxc profile set default snapshots.expiry="3d"
lxc profile set default snapshots.schedule="@daily, @startup"

After the recovery:

root@prod-lxd-images:~# lxc profile show default
name: default
description: Default LXD profile
config: {}
devices: {}
used_by:
- /1.0/instances/images

[tomponline]

Just went through a lxd recover (see #14753) and the default profile obtained in the end lacked all the configs it initially had.

Initially, the default profile was created with:

lxc profile set default security.syscalls.deny="$(echo -e 'io_uring_setup\nio_uring_enter\nio_uring_register')"
lxc profile set default security.protection.delete=true
lxc profile set default security.syscalls.deny_compat=true
lxc profile set default snapshots.expiry="3d"
lxc profile set default snapshots.schedule="@daily, @startup"

After the recovery:

root@prod-lxd-images:~# lxc profile show default
name: default
description: Default LXD profile
config: {}
devices: {}
used_by:
- /1.0/instances/images

I think that's to be expected because its for instance recovery not server recovery.

Yes the profile config is stored in the instance's backup.yaml file, but modifying the server's existing profile with settings from (potentially multiple conflicting) instance backup.yaml files seems problematic and risky.

[simondeziel]

Yes the profile config is stored in the instance's backup.yaml file, but modifying the server's existing profile with settings from (potentially multiple conflicting) instance backup.yaml files seems problematic and risky.

Fair point but that lxd was not initialized so it had no prior default profile.

[tomponline]

Yes the profile config is stored in the instance's backup.yaml file, but modifying the server's existing profile with settings from (potentially multiple conflicting) instance backup.yaml files seems problematic and risky.

Fair point but that lxd was not initialized so it had no prior default profile.

If memory serves one is created on startup, so technically it did have an empty one. Maybe there's some room for maneuver there.

[simondeziel]

I think that's to be expected because its for instance recovery not server recovery.

Yeah, that's probably the key distinction here. I've always been using lxd recovery to recover from lost servers. IIRC, that's also what we suggest in those situations and I vaguely remember folks (ab)using it to that effect.

Since it's an interactive tool, having additional questions to support the "server recovery" scenario would be useful IMHO.

[tomponline]

@roosterfish this might be worth considering whilst you are looking into lxd recover.

Can I assign this to you?

[tomponline]

@roosterfish is this covered by one of your recent PRS?

[roosterfish]

@roosterfish is this covered by one of your recent PRS?

Haven't touched this part. Probably we should prompt the user if one of the profiles on LXD doesn't match to what we have discovered from the most recent instance's backup config (using the new metadata which allows checking the file's modification time).

But let's land this separately.