Lxd: Storage management API

[pcdummy]

Currently you can mount anyhthing on the host of LXD, setfacl/chown it and then bind mount into the container. But you loose the ability to live migrate the given container and this is a error-prone and manual procedure, you could ofc automate it with tools like Saltstack/Ansible/Puppet/uvm.

In this ticket i want to discuss a feature to automate all of this in a REST-API friendly way.

I think LXD should be able to do the following for us on local volumes:

• Create a directory / BTRFS / ZFS / LVM Volume
• Allow us to set Quotas and stuff
• Attach the Volume to one ore more containers.
• Setfacl and/or chown it by automaticaly translating uids and gids to unprivileged ones - doing that once or on every activation.
• Activate on the container
• Live migrate containers with volumes attached to containers with the same "Volume Storage Engine"

Volumes shouldn't be limited to local Volumes, there should be also a way to handle remote Volumes in the same manner:

• Mount NFS/GlusterFS/CephFS/CIFS/uvm.
• Attach to a container
• Maybe chown/setfacl
• Activate on the container

What do you think about that feature, is that something core devs/canoncial wants?
I'm willing to implement large parts of this feature if people agree with it.

[stgraber]

This is somewhat related to #1784.

We'll want to implement an API (/1.0/storage) that lets you list, create, delete and modify storage pools. We'd then need a few changes here and there to the "disk" device type to allow specifying what pool to allocate from and possibly also let you allocate additional volumes.

[pcdummy]

And that Setfacl/chown stuff? Also whats about remote "volumes" ?

[wtayyeb]

+1

[stgraber]

We'll be using this issue to track the upcoming work on storage API.

The scope of what we have planned is:

• Support for multiple storage pools
• Support for allocating container from specific pools at creation time
• Support for standalone volume creation within pools
• Support for attaching/detaching volumes to specified container paths (disk device entry)

All of the above will be available through the REST API and be built using the existing storage drivers. We'll try to keep things simple and not mix new storage drivers or new features into the mix at this time.

[tomposmiko]

If LVM Volume works, why don't you add support for other volumes like Ceph and ZFS volumes?
I'm just curious.

[stgraber]

The LVM backend is probably the most annoying backend we've got right now, basically anything which is block based is painful when you have to deal with migration, resize, shrink, ...

So we will support LVM with this code and have kept in mind the restrictions of block based volumes in the design, but we won't be trying to get more of them done with this work.

Supporting ceph is still on the roadmap as something we may do later, see #1258 but will not be part of the first pass on this feature.

[tomposmiko]

Very good, thanks!