Hi,
I am working on this, as you know:
https://github.com/cockpit-project/cockpit/wiki/Atomic:-Docker-Storage
and after getting my misunderstandings of docker-storage-setup cleared
up, my next idea is to change the "atomic" command to pretty directly
support those use cases.
We need two operations:
- Take a block device and use it for storing Docker images and
containers.
- Reset the docker storage setup so that block devices that were
previously used for storing Docker images and containers are
available again for other uses.
We need the following information:
- A list of block devices that are currently used to store Docker
images and containers.
- A notification when that list changes.
(As a proper API, of course.)
What about the following?
- We implement "atomic container-storage add DEV" and "atomic
container-storage reset".
- We make "atomic" maintain a file in /var with the status of the
Docker storage pool, in JSON, with atomic updates.
Clients like Cockpit can watch the status file with inotify or similar
and get notifications that way.
The "add" operation would append the given block device to the DEVS line
in /etc/sysconfig/docker-storage-setup" and run docker-storage-setup.
The "reset" operation would
- systemctl stop docker
- rm -rf /var/lib/docker
- set DEVS="" in /etc/sysconfig/docker-storage-setup
- run "docker-storage-setup reset"
With the "devicemapper" backend using a thin pool, "d-s-s reset" would
- rm /etc/sysconfig/docker-storage
- remove the thinpool
- vgreduce all pvs that are now completely empty
I don't yet know what "d-s-s reset" could do for other backends or a
devicemapper with loopbacks.
The status file would contain at least the list of block devices
successfully given to "add" since the last "reset".
Would it be appropriate to put the docker storage pool behind an
abstraction like this? Or should we rather expose the LVM2 details and
let people tweak them directly?
Thoughts?
