`juju clouds` fails with `ERROR cmd: error out silently` when it cannot reach the controller in a Kubernetes cluster

[Jonatas Baldin]

How to reproduce:

1. Get a K8S cluster up and running, like Minikube.
2. Bootstrap juju there.
3. Delete the cluster.
4. Get a new cluster, Minikube or any other platform.

Juju commands start to fail:

```
$ juju clouds
WARNING starting proxy for api connection: Get "https://192.168.64.5:16443/api/v1/namespaces/controller-my-k8s-localhost/services/controller-service": dial tcp 192.168.64.5:16443: i/o timeout
ERROR cmd: error out silently
```

```
$ juju status
ERROR starting proxy for api connection: Get "https://192.168.64.5:16443/api/v1/namespaces/controller-my-k8s-localhost/services/controller-service": dial tcp 192.168.64.5:16443: i/o timeout
```

Fixed by unregistering the controller:
```
$ juju unregister my-k8s-localhost
```

```
$ juju version
2.9-rc6-catalina-amd64
```

[Joseph Phillips (manadart)]

Clouds can be registered on your client and/or a controller, so the command attempts to access the current controller.

We could conceivably enhance this experience to write the clouds that can be gleaned from the client to stdout and print the controller access error to stderr...

[Robert Gildein (rgildein)]

After restarting my PC, I run into the same problem. I'm using microk8s cluster.

```bash
$ juju status
ERROR starting proxy for api connection: Get "https://172.20.10.5:16443/api/v1/namespaces/controller-k8s/services/controller-service": dial tcp 172.20.10.5:16443: i/o timeout
```

How to reproduce:

 * install microk8s
 * enable dns ingress registry storage
 * bootstrap the controller
 * restart PC

microk8s inspect:
```bash
$ microk8s inspect
Inspecting Certificates
Inspecting services
  Service snap.microk8s.daemon-cluster-agent is running
  Service snap.microk8s.daemon-containerd is running
  Service snap.microk8s.daemon-apiserver is running
  Service snap.microk8s.daemon-apiserver-kicker is running
  Service snap.microk8s.daemon-control-plane-kicker is running
  Service snap.microk8s.daemon-proxy is running
  Service snap.microk8s.daemon-kubelet is running
  Service snap.microk8s.daemon-scheduler is running
  Service snap.microk8s.daemon-controller-manager is running
  Copy service arguments to the final report tarball
Inspecting AppArmor configuration
Gathering system information
  Copy processes list to the final report tarball
  Copy snap list to the final report tarball
  Copy VM name (or none) to the final report tarball
  Copy disk usage information to the final report tarball
  Copy memory usage information to the final report tarball
  Copy server uptime to the final report tarball
  Copy current linux distribution to the final report tarball
  Copy openSSL information to the final report tarball
  Copy network configuration to the final report tarball
Inspecting kubernetes cluster
  Inspect kubernetes cluster
Inspecting juju
  Inspect Juju
Inspecting kubeflow
  Inspect Kubeflow

Building the report tarball
  Report tarball is at /var/snap/microk8s/2213/inspection-report-20210524_081911.tar.gz
```

versions:
```bash
$ snap list | grep 'juju\|microk8s'
juju 2.9.0 16132 latest/stable canonical* classic
microk8s v1.20.7 2213 1.20/stable canonical* classic
```

[John A Meinel (jameinel)]

So if your machine restarted and the kubernetes cluster shows up at a
different IP address, I believe you can look at
~/.local/share/controllers.yaml and see if you can update that address to
the new address of the controller.

On Mon, May 24, 2021 at 2:40 AM Robert Gildein <email address hidden>
wrote:

> After restarting my PC, I run into the same problem. I'm using microk8s
> cluster.
>
> ```bash
> $ juju status
> ERROR starting proxy for api connection: Get "
> https://172.20.10.5:16443/api/v1/namespaces/controller-k8s/services/controller-service":
> dial tcp 172.20.10.5:16443: i/o timeout
> ```
>
> How to reproduce:
>
> * install microk8s
> * enable dns ingress registry storage
> * bootstrap the controller
> * restart PC
>
> microk8s inspect:
> ```bash
> $ microk8s inspect
> Inspecting Certificates
> Inspecting services
> Service snap.microk8s.daemon-cluster-agent is running
> Service snap.microk8s.daemon-containerd is running
> Service snap.microk8s.daemon-apiserver is running
> Service snap.microk8s.daemon-apiserver-kicker is running
> Service snap.microk8s.daemon-control-plane-kicker is running
> Service snap.microk8s.daemon-proxy is running
> Service snap.microk8s.daemon-kubelet is running
> Service snap.microk8s.daemon-scheduler is running
> Service snap.microk8s.daemon-controller-manager is running
> Copy service arguments to the final report tarball
> Inspecting AppArmor configuration
> Gathering system information
> Copy processes list to the final report tarball
> Copy snap list to the final report tarball
> Copy VM name (or none) to the final report tarball
> Copy disk usage information to the final report tarball
> Copy memory usage information to the final report tarball
> Copy server uptime to the final report tarball
> Copy current linux distribution to the final report tarball
> Copy openSSL information to the final report tarball
> Copy network configuration to the final report tarball
> Inspecting kubernetes cluster
> Inspect kubernetes cluster
> Inspecting juju
> Inspect Juju
> Inspecting kubeflow
> Inspect Kubeflow
>
> Building the report tarball
> Report tarball is at
> /var/snap/microk8s/2213/inspection-report-20210524_081911.tar.gz
> ```
>
> versions:
> ```bash
> $ snap list | grep 'juju\|microk8s'
> juju 2.9.0 16132 latest/stable
> canonical* classic
> microk8s v1.20.7 2213 1.20/stable
> canonical* classic
> ```
>
> --
> You received this bug notification because you are subscribed to juju.
> Matching subscriptions: juju bugs
> https://bugs.launchpad.net/bugs/1914261
>
> Title:
> `juju clouds` fails with `ERROR cmd: error out silently` when it
> cannot reach the controller in a Kubernetes cluster
>
> To manage notifications about this bug go to:
> https://bugs.launchpad.net/juju/+bug/1914261/+subscriptions
>

[Canonical Juju QA Bot (juju-qa-bot)]

This Medium-priority bug has not been updated in 60 days, so we're marking it Low importance. If you believe this is incorrect, please update the importance.