What happened:
I was unable to start kind on Windows with hostPath set to /c/temp
What you expected to happen:
I expected to start kind on Windows with hostPath set to /c/temp
How to reproduce it (as minimally and precisely as possible):
Start kind with the following config
cfg.yml
kind: Cluster
apiVersion: kind.x-k8s.io/v1alpha4
nodes:
- role: control-plane
extraMounts:
- containerPath: /opt/local-path-provisioner
hostPath: /c/temp
readOnly: false
kind create cluster --config cfg.yml
Anything else we need to know?:
I applied the following workaround
--- a/pkg/cluster/internal/providers/docker/provision.go 2020-02-10 22:28:08.601828100 +0200
+++ b/pkg/cluster/internal/providers/docker/provision.go 2020-02-10 22:29:04.711607700 +0200
@@ -19,7 +19,6 @@
import (
"fmt"
"net"
- "path/filepath"
"strings"
"sigs.k8s.io/kind/pkg/cluster/constants"
@@ -61,16 +60,6 @@
node := node.DeepCopy() // copy so we can modify
name := nodeNamer(string(node.Role)) // name the node
- // fixup relative paths, docker can only handle absolute paths
- for i := range node.ExtraMounts {
- hostPath := node.ExtraMounts[i].HostPath
- absHostPath, err := filepath.Abs(hostPath)
- if err != nil {
- return nil, errors.Wrapf(err, "unable to resolve absolute path for hostPath: %q", hostPath)
- }
- node.ExtraMounts[i].HostPath = absHostPath
- }
-
// plan actual creation based on role
switch node.Role {
case config.ControlPlaneRole:
Environment:
kind version): v0.7.0Kubernetes version: (use kubectl version):
Client Version: version.Info{Major:"1", Minor:"17", GitVersion:"v1.17.0", GitCommit:"70132b0f130acc0bed193d9ba59dd186f0e634cf", GitTreeState:"clean", BuildDate:"2019-12-07T21:20:10Z", GoVersion:"go1.13.4", Compiler:"gc", Platform:"windows/amd64"}
Server Version: version.Info{Major:"1", Minor:"17", GitVersion:"v1.17.0", GitCommit:"70132b0f130acc0bed193d9ba59dd186f0e634cf", GitTreeState:"clean", BuildDate:"2020-01-14T00:09:19Z", GoVersion:"go1.13.4", Compiler:"gc", Platform:"linux/amd64"}
Docker version: (use docker info):
Client:
Debug Mode: false
Server:
Containers: 2
Running: 2
Paused: 0
Stopped: 0
Images: 1
Server Version: 19.03.5
Storage Driver: overlay2
Backing Filesystem: extfs
Supports d_type: true
Native Overlay Diff: true
Logging Driver: json-file
Cgroup Driver: cgroupfs
Plugins:
Volume: local
Network: bridge host ipvlan macvlan null overlay
Log: awslogs fluentd gcplogs gelf journald json-file local logentries splunk syslog
Swarm: inactive
Runtimes: runc
Default Runtime: runc
Init Binary: docker-init
containerd version: b34a5c8af56e510852c35414db4c1f4fa6172339
runc version: 3e425f80a8c931f88e6d94a8c831b9d5aa481657
init version: fec3683
Security Options:
seccomp
Profile: default
Kernel Version: 4.14.154-boot2docker
Operating System: Boot2Docker 19.03.5 (TCL 10.1)
OSType: linux
Architecture: x86_64
CPUs: 1
Total Memory: 989.5MiB
Name: kind
ID: A4W7:F5TO:SQMC:2XKF:MING:LCHG:ME5N:CURZ:QTXN:5PXZ:F7YW:H3ZS
Docker Root Dir: /mnt/sda1/var/lib/docker
Debug Mode: false
Registry: https://index.docker.io/v1/
Labels:
provider=virtualbox
Experimental: false
Insecure Registries:
127.0.0.0/8
Live Restore Enabled: false
Product License: Community Engine
OS (e.g. from /etc/os-release):
Microsoft Windows [Version 10.0.18363.628]
so that workaround cannot be merged because we allow relative paths and docker does not.
however, we can maybe check IsAbs first. on linux at least this is already internally checked in Abs IIRC, but perhaps the windows implementation is less ideal
On windows IsAbs is not inspected inside the private abs implementation https://golang.org/src/path/filepath/path_windows.go
Probably a check to IsAbs before deciding to resolve to an absolute path would fix this, but it's difficult to confirm without a windows machine handy at the moment, I have one at home and could confirm tonight, but not at the office.
If you can confirm that this work around would work, that would be great.
@BenTheElder I'll try to revisit my PR when I find time
I ran something like this on my personal windows machine with go1.13:
package main
import (
"path/filepath"
"fmt"
)
func main() {
fmt.Println(filepath.IsAbs("/c/temp"))
}
and it prints false ... :|
_is_ /c/temp an absolute path? why doesn't it have a drive letter ...? is this a path inside the docker desktop VM?
It is special POSIX path mapping only available in Windows, the main idea is to provide support both Windows-style paths, and Unix-style paths. In reality ugly hack with many edge-cases, and many cross-platform tools struggling implementing proper compatibility with it. This /c/temp will be converted to usual c:\temp path under the hood, which is in turn will be understandable by Windows API.
this should be handled in HEAD now by just also considering posix style absolute paths always.
I have some thoughts on a more elaborate solution, but this should sanely resolve this particular issue