Re: [atomic-devel] Storage use cases for the "atomic" command

[Clayton Coleman <ccoleman redhat com>]

Kubernetes in some cases will be directly reading the info from the
filesystem/kernel and summarizing that up to the control plane, so
possibly less useful to do the fsnotify work when atomic is a Kube
node.  However, definitely may have value in other atomic use cases.

> On Apr 15, 2016, at 8:53 AM, Marius Vollmer <marius vollmer redhat com> wrote:
>
> 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?
>