The extended API would certainly be welcomed. However, after thinking a while, I am not sure it is a direct responsibility of IncusOS to manage disks. In addtion to disk encryption, there could be other disk configurations such as cache tiering or software raid, also stacked upon one another. For example, we use LUKS encryption on top of Bcache devices. I think managing all such configurations using IncusOS API is unrealistic.
As mentioned, it is possible to unlock an encrypted disk from a privilledged container, so, as long as it is conceptually OK to “poke” inside IncusOS, one can use such temporary containers to manage storage devices and other hardware. I just tested and it appears that the linstor-satellite services are OK also if the disk for the storage volume becomes available after the service has started. Of course, one should probably start these management containers with a higher priority so that the remote storage is available before it is used by other containers.
I have a related question about the design of IncusOS applications. It looks like incus-linstor provides linstor-satellite services, but incus-ceph does not provide similar ceph-osd services, probably assuming that they should run in containers. Can one similarly install and run linstor-satellite services in containers, without using incus-linstor application at all? Running the satellite services in containers could be more reliable if the storage devices need to be initialized before the services have started. Also, it is easier to keep the versions of satellites and controllers in sync. Or is it planned to also add other services such as linstor-controller to the incus-linstor application to provide a complete solution?