[Date Prev][Date Next]   [Thread Prev][Thread Next]   [Thread Index] [Date Index] [Author Index]

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

On 04/15/2016 08:53 AM, Marius Vollmer wrote:

I am working on this, as you know:


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

  - 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?


I am fine with this, but I would like to try to keep this container platform agnostic if at all possible. We are moving to support other frameworks, and potentially getting the COW file system management (graphc) out of
docker directly so it could be used by others

[Date Prev][Date Next]   [Thread Prev][Thread Next]   [Thread Index] [Date Index] [Author Index]