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.voll...@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? >
