Preserve custom/c1 syntax during storage volume rename

[MggMuggins]

Follow-up to #14491; if a volume is specified as source: custom/c1, then a rename of c1->c2 should leave the device with source: custom/c2.

[tomponline]

@MggMuggins TIL LXD does this.

[MggMuggins]

You and me both 😆

[MggMuggins]

@tomponline There's no bug when used with instance devices. Renaming devices attached to profiles fails, but with an unhelpful error message.

Instances

Assume the following configuration in a lxd cluster with cluster members c1, c2, and c3:

$ lxc ls
+------+---------+------+------+-----------------+-----------+----------+
| NAME |  STATE  | IPV4 | IPV6 |      TYPE       | SNAPSHOTS | LOCATION |
+------+---------+------+------+-----------------+-----------+----------+
| v1   | STOPPED |      |      | VIRTUAL-MACHINE | 0         | c1       |
+------+---------+------+------+-----------------+-----------+----------+
| v2   | STOPPED |      |      | VIRTUAL-MACHINE | 0         | c2       |
+------+---------+------+------+-----------------+-----------+----------+
$ lxc storage volume ls
+-------+-----------------+--------------------------------------------------+-------------+--------------+---------+----------+
| POOL  |      TYPE       |                       NAME                       | DESCRIPTION | CONTENT-TYPE | USED BY | LOCATION |
+-------+-----------------+--------------------------------------------------+-------------+--------------+---------+----------+
| local | custom          | blk1                                             |             | block        | 1       | c1       |
+-------+-----------------+--------------------------------------------------+-------------+--------------+---------+----------+
| local | custom          | blk1                                             |             | block        | 1       | c2       |
+-------+-----------------+--------------------------------------------------+-------------+--------------+---------+----------+
...
+-------+-----------------+--------------------------------------------------+-------------+--------------+---------+----------+
| local | virtual-machine | v1                                               |             | block        | 1       | c1       |
+-------+-----------------+--------------------------------------------------+-------------+--------------+---------+----------+
| local | virtual-machine | v2                                               |             | block        | 1       | c2       |
+-------+-----------------+--------------------------------------------------+-------------+--------------+---------+----------+
$ lxc config show v1
...
devices:
  blk1:
    pool: local
    source: blk1
    type: disk
ephemeral: false
profiles:
- default
- ...
$ lxc config show v2
...
devices:
  blk1:
    pool: local
    source: blk1
    type: disk
ephemeral: false
profiles:
- default
...

Renaming blk1 on c1 only modifies the disk device on v1:

$ lxc storage volume rename local blk1 blk2 --target c1
Renamed storage volume from "blk1" to "blk2"
$ lxc config show v1
...
devices:
  blk1:
    pool: local
    source: blk2
    type: disk
ephemeral: false
profiles:
- default
...
$ lxc config show v2
...
devices:
  blk1:
    pool: local
    source: blk1
    type: disk
ephemeral: false
profiles:
- default
...

Profiles

The block volume sharing rules aren't strictly correct; adding the same device to the default profile hits this:

$ lxc profile device add default blk1 disk pool=local source=blk1
Config parsing error: Device validation failed for "blk1": Cannot add custom storage block volume to profiles if security.shared is false or unset

Setting that aside for a moment, the rename fails here:

$ lxc storage volume set local blk1 security.shared=true --target c1
$ lxc storage volume set local blk1 security.shared=true --target c2
$ lxc storage volume rename local blk1 blk2 --target c1
Error: Device validation failed for "blk1": Failed loading custom volume: Storage volume not found

I tried a similar setup with filesystem volumes in profiles and get the same thing. I think the current implementation is sound, at least insofar as it validates changes after making them.

Looking at the code I think there's a corner case involving how revert happens (or not) when the rename fails like this, but I need a little more time to work it out properly.

cc @masnax