Difficult to execute commands when currentContext is invalid

[kinghuang]

Description

If the current context is not valid, it is not easy to run any CLI commands, including switching to a valid context.

Steps to reproduce the issue:

Assume there are contexts named default and context-two.

1. Make context-two the current context.
2. Set DOCKER_CONTEXT=default to override it in the current shell.
3. Remove context-two.
4. Attempt to do something with the Docker CLI, like docker version.

$ docker context ls --format 'table {{ .Name }}\t{{ .Current }}'
NAME                <no value>
context-two         true
default             false
$ export DOCKER_CONTEXT=default
$ docker context rm context-two
context-two

Describe the results you received:

Any CLI operation results in an error. It is not possible to switch to a valid context using docker context use ….

$ docker version
Current context "context-two" is not found on the file system, please check your config file at /Users/king.huang/.docker/config.json
$ docker context use default
Current context "context-two" is not found on the file system, please check your config file at /Users/king.huang/.docker/config.json

Describe the results you expected:

It should be possible to at least list and switch to a valid context.

Additional information you deem important (e.g. issue happens only occasionally):

When removing the current context specified in config.json, perhaps the CLI should change the value of currentContext to something like default.

The current context can be fixed by editing config.json manually, or using the DOCKER_CONTEXT environment variable to switch to a valid context, and then using a valid context.

$ export DOCKER_CONTEXT=default
$ docker context use default
default
Current context is now "default"

Output of docker version:

Client: Docker Engine - Community
 Version:           19.03.0-rc2
 API version:       1.40
 Go version:        go1.12.5
 Git commit:        f97efcc
 Built:             Wed Jun  5 01:37:53 2019
 OS/Arch:           darwin/amd64
 Experimental:      true

Server: Docker Engine - Community
 Engine:
  Version:          19.03.0-rc2
  API version:      1.40 (minimum version 1.12)
  Go version:       go1.12.5
  Git commit:       f97efcc
  Built:            Wed Jun  5 01:42:10 2019
  OS/Arch:          linux/amd64
  Experimental:     true
 containerd:
  Version:          v1.2.6
  GitCommit:        894b81a4b802e4eb2a91d1ce216b8817763c29fb
 runc:
  Version:          1.0.0-rc8
  GitCommit:        425e105d5a03fabd737a126ad93d62a9eeede87f
 docker-init:
  Version:          0.18.0
  GitCommit:        fec3683

Output of docker info:

Client:
 Debug Mode: false
 Plugins:
  app: Docker Application (Docker Inc., v0.8.0-rc1)
  buildx: Build with BuildKit (Docker Inc., v0.2.2-tp-docker)

Server:
 Containers: 0
  Running: 0
  Paused: 0
  Stopped: 0
 Images: 300
 Server Version: 19.03.0-rc2
 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: active
  NodeID: ilntgb4sbycucyl3iiva1wk3p
  Is Manager: true
  ClusterID: wsz99afbhy169obu69h1eq7z0
  Managers: 1
  Nodes: 1
  Default Address Pool: 10.0.0.0/8  
  SubnetSize: 24
  Data Path Port: 4789
  Orchestration:
   Task History Retention Limit: 5
  Raft:
   Snapshot Interval: 10000
   Number of Old Snapshots to Retain: 0
   Heartbeat Tick: 1
   Election Tick: 10
  Dispatcher:
   Heartbeat Period: 5 seconds
  CA Configuration:
   Expiry Duration: 3 months
   Force Rotate: 0
  Autolock Managers: false
  Root Rotation In Progress: false
  Node Address: 192.168.65.3
  Manager Addresses:
   192.168.65.3:2377
 Runtimes: runc
 Default Runtime: runc
 Init Binary: docker-init
 containerd version: 894b81a4b802e4eb2a91d1ce216b8817763c29fb
 runc version: 425e105d5a03fabd737a126ad93d62a9eeede87f
 init version: fec3683
 Security Options:
  seccomp
   Profile: default
 Kernel Version: 4.9.125-linuxkit
 Operating System: Docker Desktop
 OSType: linux
 Architecture: x86_64
 CPUs: 6
 Total Memory: 11.71GiB
 Name: docker-desktop
 ID: b5307ed3-4dc8-4eb4-b931-138544ef581f
 Docker Root Dir: /var/lib/docker
 Debug Mode: true
  File Descriptors: 45
  Goroutines: 157
  System Time: 2019-06-18T14:25:25.8970508Z
  EventsListeners: 2
 HTTP Proxy: gateway.docker.internal:3128
 HTTPS Proxy: gateway.docker.internal:3129
 Registry: https://index.docker.io/v1/
 Labels:
 Experimental: true
 Insecure Registries:
  127.0.0.0/8
 Live Restore Enabled: false
 Product License: Community Engine

Additional environment details (AWS, VirtualBox, physical, etc.):

Docker for Mac 2.0.5.0.

[thaJeztah]

Thanks for reporting; @silvin-lubecki and I are looking into this.

As you describe; setting DOCKER_CONTEXT=default should override whatever is configured in config.json, so it should not hit the faulty context.

I think what might be happening (without looking in the code; just a first thought), is that when selecting a context, some code is doing a "get all available contexts" before selecting the one that's specified.

We should prevent that from happening; even if there's an invalid context, it should (if possible) skip checking all contexts (also for performance (?)), and only care about invalid contexts if they are needed for the command that's run (either when attempting to use an invalid context, or when doing (e.g.) docker context ls)

[silvin-lubecki]

Hello @kinghuang I was trying to reproduce the issue you described, but without luck 😞

$ docker context use swarm
swarm
Current context is now "swarm"

$ DOCKER_CONTEXT=default docker context rm swarm
swarm

$ DOCKER_CONTEXT=default docker context ls
NAME                DESCRIPTION                               DOCKER ENDPOINT               KUBERNETES ENDPOINT                ORCHESTRATOR
default *           Current DOCKER_HOST based configuration   unix:///var/run/docker.sock   https://localhost:6443 (default)   swarm

$ DOCKER_CONTEXT=default docker ps
CONTAINER ID        IMAGE               COMMAND             CREATED             STATUS              PORTS               NAMES

$  docker context ls
Current context "swarm" is not found on the file system, please check your config file at /Users/silvin/.docker/config.json

$ DOCKER_CONTEXT=default docker context use default
default
Current context is now "default"

$ docker ps
CONTAINER ID        IMAGE               COMMAND             CREATED             STATUS              PORTS               NAMES

[adeniyistephen]

@silvin-lubecki @thaJeztah I would love to work on this, Please provide pointers and input on how to work on it. Thanks

[smhc]

I'd also like to see this fixed - I am often getting into this knot when switching between WSL and Windows, as the 'current context' is different between the two environments despite the list of contexts being shared.

[Kangaroux]

@silvin-lubecki @thaJeztah It would be great if this could be addressed. This should reproduce the issue:

docker context create test-ctx --docker "host=ssh://123.123.123.123"
docker context use test-ctx

Once you have a broken context the only ways to fix it seem to be:

• DOCKER_CONTEXT=default docker context use default
• Manually edit ~/.docker/config.json

[jest]

I was lucky enough to have spot this issue and connect the dots when my docker command suddenly stopped working today...

When using "invalid" context — in my case it was unreachable host — the CLI becomes broken with no way to solve, or even investigate the issue, without resorting to low-level strace'ing etc.

As "context" concept is related to connecting to docker host, a bunch of subcommands should not use the context when the connection is not necessary. At extreme, --help should not hang when there is no connection to the host!

# per @Kangaroux example
docker context create test-ctx --docker 'host=ssh://123.123.123.123'
docker context use test-ctx

docker -D --help
DEBU[0000] commandconn: starting ssh with [-l user -- 123.123.123.123 docker system dial-stdio] 

@thaJeztah @silvin-lubecki Maybe this should be specified as a separate issue?