Device override should fallback to device set

[simondeziel]

This works:

$ lxc init v1 --empty --vm
$ lxc config device override v1 root size=50GiB

But when a specific storage pool is specified during init, the device override no longer works, device set needs to be used instead:

$ lxc init v1 --empty --vm -s butter  # alternate storage pool
$ lxc config device override v1 root size=50GiB
Error: The device already exists

While that makes sense from an instance config point of view:

$ lxc config show v1
architecture: x86_64
config:
  volatile.apply_template: create
  volatile.cloud-init.instance-id: e51b383f-1f65-401a-9c2d-669cc77ecb8d
  volatile.eth0.hwaddr: 00:16:3e:f9:0c:a6
  volatile.uuid: 01dbcee9-1a26-4b01-8cea-c4d0c590a4c0
  volatile.uuid.generation: 01dbcee9-1a26-4b01-8cea-c4d0c590a4c0
devices:
  root:
    path: /
    pool: butter
    type: disk
ephemeral: false
profiles:
- default
stateful: false
description: ""

The workaround is to use device set (lxc config device set v1 root size=50GiB) but the user experience could be improved by allowing device override fallback to being a device set.

[simondeziel]

I am now unsure about the implication of my suggested behavior change. If we make device override fallback to device set, then what's the point of using device set ever?

I don't fully understand the rational for having both device override and device set so it was likely premature for me to fill out an issue for it :/

[tomponline]

Yes this does raise some interesting scenarios, like what if the device type is different in the instance than the device being overridden from the profile.

Lets hold off on this one for now.