Loss of instance permissions after storage pool migration

[mas-who]

LXD information

• lxd snap version: git-2cc542a (latest/edge)

Description

When migrating an instance between storage pools, the associated permissions (such as can_edit) assigned via an auth group are lost. This occurs because the instance record is deleted and recreated, leading to the removal of permissions (per this discussion).

Steps to reproduce

1. Assign an entitlement (e.g., can_edit) to a restricted user via an auth group for an instance.
2. Perform an instance migration to another storage pool.
3. Check the permissions for the instance after migration.

Expected behaviour

The instance should retain its assigned permissions after migration.

Actual behavior

The permissions are lost because the instance is recreated with a new record ID.

Affected scenarios

• Moving an instance between storage pools.
• Moving an instance between cluster members.

[markylaing]

The fix for this should collect permissions that are directly related to the instance before it is deleted, then set those same permissions again on the newly created copy of the instance.

[markylaing]

Ideally we would maintain the ID of the instance and update its' database record with the new cluster member ID.

[tomponline]

The fix for this should collect permissions that are directly related to the instance before it is deleted, then set those same permissions again on the newly created copy of the instance.

Thats one approach we could take.

But I'd also like to explore maintaining the ID (so not deleting the record), in order to avoid breaking other things that reference the record by ID (such as warnings and potentially replication schedules in the future).

[mas-who]

Additional note regarding moving an instance to a different cluster member:

When I tried moving an instance to a different cluster member, I get an error saying the instance cannot be found. The set of permissions I tried to do this is shown below:

Note I could migrate the instance with instance_manager entitlement for the project default, which I believe is equivalent to the set of instance permissions shown above. Am I doing something wrong with the permission required perhaps? I'm not entirely sure if this behaviour is 100% relevant to this issue, however, I think it's probably due to the sequence of operations required for instance migration (happy to open another issue if necessary).