Add possibility to add data volumes

[afbjorklund]

When provisioning machines with libmachine or with docker, only one system image or system volume is created.

/mnt/sda1

/var

It would be nice if it was possible to add a second image or a second volume, for keeping data between runs.

Typically the system partition is created and destroyed with the cluster.

But you might want to have your user data outlive the rest of the cluster ?

---

Currently there is only /data for user data, besides the internal:

https://minikube.sigs.k8s.io/docs/handbook/persistent_volumes/

$ findmnt /dev/sda1 | egrep "TARGET|^/var|^/data|^/tmp"
TARGET                    SOURCE                           FSTYPE OPTIONS
/var/lib/boot2docker      /dev/sda1[/var/lib/boot2docker]  ext4   rw,relatime
/var/lib/docker           /dev/sda1[/var/lib/docker]       ext4   rw,relatime
/var/lib/containerd       /dev/sda1[/var/lib/containerd]   ext4   rw,relatime
/var/lib/buildkit         /dev/sda1[/var/lib/buildkit]     ext4   rw,relatime
/var/lib/containers       /dev/sda1[/var/lib/containers]   ext4   rw,relatime
/var/log                  /dev/sda1[/var/log]              ext4   rw,relatime
/var/tmp                  /dev/sda1[/var/tmp]              ext4   rw,relatime
/var/lib/kubelet          /dev/sda1[/var/lib/kubelet]      ext4   rw,relatime
/var/lib/cni              /dev/sda1[/var/lib/cni]          ext4   rw,relatime
/data                     /dev/sda1[/data]                 ext4   rw,relatime
/tmp/hostpath_pv          /dev/sda1[/hostpath_pv]          ext4   rw,relatime
/tmp/hostpath-provisioner /dev/sda1[/hostpath-provisioner] ext4   rw,relatime
/var/lib/minikube         /dev/sda1[/var/lib/minikube]     ext4   rw,relatime
/var/lib/toolbox          /dev/sda1[/var/lib/toolbox]      ext4   rw,relatime
/var/lib/minishift        /dev/sda1[/var/lib/minishift]    ext4   rw,relatime

docker@minikube:~$ findmnt /dev/mapper/ubuntu--vg-root | egrep "TARGET|^/var|^/data|^/tmp"
TARGET                    SOURCE                                                                                                                               FSTYPE OPTIONS
/var                      /dev/mapper/ubuntu--vg-root[/var/lib/docker/volumes/minikube/_data]                                                                  ext4   rw,relatime,errors=remount-ro
/data                     /dev/mapper/ubuntu--vg-root[/var/lib/docker/volumes/minikube/_data/data]                                                             ext4   rw,relatime,errors=remount-ro
/tmp/hostpath_pv          /dev/mapper/ubuntu--vg-root[/var/lib/docker/volumes/minikube/_data/hostpath_pv]                                                      ext4   rw,relatime,errors=remount-ro
/tmp/hostpath-provisioner /dev/mapper/ubuntu--vg-root[/var/lib/docker/volumes/minikube/_data/hostpath-provisioner]                                             ext4   rw,relatime,errors=remount-ro

The difference in /var mounts is for historical reasons, machine vs kind.

[afbjorklund]

Talked about this in #3318 (comment) when discussing the mount point location (path)
Typically you would use something like /mnt rather than /tmp, for doing the mounts...

• /tmp/hostpath_pv
• /tmp/hostpath-provisioner

We changed from using symlinks to bind-mounts, because of some "clever" software.
It would use readlink and friends, and refuse to cooperate with something like /data:

35bba7a "Use bind mount instead symlink"

c2b00e4 "Configure /data as a persisted directory."

[k8s-triage-robot]

The Kubernetes project currently lacks enough contributors to adequately respond to all issues and PRs.

This bot triages issues and PRs according to the following rules:

• After 90d of inactivity, lifecycle/stale is applied
• After 30d of inactivity since lifecycle/stale was applied, lifecycle/rotten is applied
• After 30d of inactivity since lifecycle/rotten was applied, the issue is closed

You can:

• Mark this issue or PR as fresh with /remove-lifecycle stale
• Mark this issue or PR as rotten with /lifecycle rotten
• Close this issue or PR with /close
• Offer to help out with Issue Triage

Please send feedback to sig-contributor-experience at kubernetes/community.

/lifecycle stale

[k8s-triage-robot]

The Kubernetes project currently lacks enough active contributors to adequately respond to all issues and PRs.

This bot triages issues and PRs according to the following rules:

• After 90d of inactivity, lifecycle/stale is applied
• After 30d of inactivity since lifecycle/stale was applied, lifecycle/rotten is applied
• After 30d of inactivity since lifecycle/rotten was applied, the issue is closed

You can:

• Mark this issue or PR as fresh with /remove-lifecycle rotten
• Close this issue or PR with /close
• Offer to help out with Issue Triage

Please send feedback to sig-contributor-experience at kubernetes/community.

/lifecycle rotten