kubernetes/minikube

Allow alternative storage-driver to be selected

Open

#7,933 opened on Apr 29, 2020

View on GitHub
 (13 comments) (0 reactions) (0 assignees)Go (31,799 stars) (5,222 forks)batch import
co/docker-driverco/preloadhelp wantedkind/featurelifecycle/frozenpriority/backlog

Description

Steps to reproduce the issue:

Host is Ubuntu 20.04 using ext4 filesystem, with additional mounted NTFS partition.

Docker info:

Client: Docker Engine - Community Version: 19.03.8 API version: 1.40 Go version: go1.12.17 Git commit: afacb8b7f0 Built: Wed Mar 11 01:25:46 2020 OS/Arch: linux/amd64 Experimental: false

Server: Docker Engine - Community Engine: Version: 19.03.8 API version: 1.40 (minimum version 1.12) Go version: go1.12.17 Git commit: afacb8b7f0 Built: Wed Mar 11 01:24:19 2020 OS/Arch: linux/amd64 Experimental: false containerd: Version: 1.2.13 GitCommit: 7ad184331fa3e55e52b890ea95e65ba581ae3429 runc: Version: 1.0.0-rc10 GitCommit: dc9208a3303feef5b3839f4323d9beb36df0a9dd docker-init: Version: 0.18.0 GitCommit: fec3683

  1. modify docker configuration to use a different storage folder and storage driver for NTFS filesystem:
{
   "graph": "/path/to/new/docker_folder_on_NTFS_filesystem",   
   "storage-driver": "vfs"
}
  1. start a fresh (no .minikube and .kube folders exist in user home) minikube cluster using docker driver: minikube start --driver=docker

Full output of failed command:

The command per se does not fail, but it pulls the wrong tarball:

preloaded-images-k8s-v2-v1.18.0-docker-overlay2-amd64.tar.lz4

which is incompatible with the target NTFS filesystem. There is no possibility to specify a different storage driver via additional parameters and also it appears no image with different storage driver exists at all under the pull location: https://storage.googleapis.com/minikube-preloaded-volume-tarballs/

The interesting part is that no error is thrown during startup, but the process will hang towards the end outputting multiple times lines such as:

Error dialing TCP: ssh: handshake failed: read tcp 127.0.0.1:51590->127.0.0.1:39697: read: connection reset by peer

it will then leave the container running, but inaccessible.

Reverting back the docker configuration to use local ext4 filesystem, for example /var/lib/docker makes the process complete successfully and lets the cluster start correctly.

Would it be possible to provide preloaded tarballs that do NOT rely on overlay storage driver? Alternatively, would it be possible to provide configuration options to specify the desired storage driver and let the local process create the correct folders at startup?

Full output of minikube start command used, if not already included:

Optional: Full output of minikube logs command:

Contributor guide

Tech stack
godocker
Domain
devopscli
Issue type
feature
DifficultyEstimated implementation difficulty for a new contributor, from 1 for very small changes to 5 for expert-level work.
3
Estimated timeA rough time range for an experienced contributor to investigate, implement, test, and prepare a pull request.
half day
Activity statusHow available the issue appears right now: fresh, active, stale, blocked, or waiting on maintainer input.
stale
ClarityHow clearly the issue explains the expected change, acceptance criteria, and next step.
clear
Prerequisites
Basic Go knowledgeDocker storage driver conceptsMinikube architecture
Newbie friendlinessA 1-100 score estimating how approachable this issue is for first-time contributors.
50
Research direction
Investigate minikube's image download logic in the codebase, focusing on how the storage driver is currently determined and how the preloaded tarball name is constructed. Modify the start command to accept a storage driver flag or infer it from Docker daemon configuration. Ensure compatibility with different filesystems.