Error setting context 'main' panicked at 'Result::unwrap()'

[SanFranciscoSunrise]

I'm thinking this error has something to do with authentication...but really not sure.
The docs are a little light on how to authenticate, or does that happen automatically by way of kubectl being authenticated already? I am using minikube here.

I can see the minikube context with 'contexts', but when I type 'context minikube'...

I am getting this error:

    [none] [none] [none] > context minikube
    thread 'main' panicked at 'called `Result::unwrap()` on an `Err` value: ()', 
    src/libcore/result.rs:1009:5
    note: Run with `RUST_BACKTRACE=1` for a backtrace.

and with backtrace:

    thread 'main' panicked at 'called `Result::unwrap()` on an `Err` value: ()', 
    src/libcore/result.rs:1009:5
    stack backtrace:
       0: std::sys::unix::backtrace::tracing::imp::unwind_backtrace
                 at src/libstd/sys/unix/backtrace/tracing/gcc_s.rs:49
       1: std::sys_common::backtrace::_print
                 at src/libstd/sys_common/backtrace.rs:71
       2: std::panicking::default_hook::{{closure}}
                 at src/libstd/sys_common/backtrace.rs:59
                 at src/libstd/panicking.rs:211
       3: std::panicking::default_hook
                 at src/libstd/panicking.rs:227
       4: std::panicking::rust_panic_with_hook
                 at src/libstd/panicking.rs:491
       5: std::panicking::continue_panic_fmt
                 at src/libstd/panicking.rs:398
       6: rust_begin_unwind
                 at src/libstd/panicking.rs:325
       7: core::panicking::panic_fmt
                 at src/libcore/panicking.rs:95
       8: core::result::unwrap_failed
       9: click::certs::try_ip_to_name
      10: click::kube::Kluster::new
      11: click::config::Config::cluster_for_context
      12: click::Env::set_context
      13: <click::cmd::Context as click::cmd::Cmd>::exec
      14: click::main
      15: std::rt::lang_start::{{closure}}
      16: std::panicking::try::do_call
                 at src/libstd/rt.rs:59
                 at src/libstd/panicking.rs:310
      17: __rust_maybe_catch_panic
                 at src/libpanic_unwind/lib.rs:102
      18: std::rt::lang_start_internal
                 at src/libstd/panicking.rs:289
                 at src/libstd/panic.rs:398
                 at src/libstd/rt.rs:58
      19: main
      20: __libc_start_main
      21: _start

[nickgronow]

I get the same error. Most commands are giving me Result::unwrap() errors as well. Installed 0.4.0 yesterday on Ubuntu 18.10.

[maver1ck]

Same error here

root@ip-10-0-0-153:~# kubectl version
Client Version: version.Info{Major:"1", Minor:"13", GitVersion:"v1.13.3", GitCommit:"721bfa751924da8d1680787490c54b9179b1fed0", GitTreeState:"clean", BuildDate:"2019-02-01T20:08:12Z", GoVersion:"go1.11.5", Compiler:"gc", Platform:"linux/amd64"}
Server Version: version.Info{Major:"1", Minor:"13", GitVersion:"v1.13.3", GitCommit:"721bfa751924da8d1680787490c54b9179b1fed0", GitTreeState:"clean", BuildDate:"2019-02-01T20:00:57Z", GoVersion:"go1.11.5", Compiler:"gc", Platform:"linux/amd64"}

[SanFranciscoSunrise]

Is this maintained? Sure looked useful, hope it is.

[nicklan]

Yep, it's just not the only thing I work on. I'll be looking into this today, thanks for the report.

[nicklan]

This is due to webpki not being able to validate the ip address as a valid dns name. This is an open issue with webpki here: briansmith/webpki#54 (i've left a comment asking if I can help resolve that issue). Until that's solved, there's no way for me to make this "just work". That being said, there is a workaround:

WORKAROUND (kinda gross I know):

1. You'll need the IP address the minikube cluster is running at. You can get this from the server: line in .kube/config for minikube. By default it looks like:

- cluster:
    certificate-authority: /home/[user]/.minikube/ca.crt
    server: https://192.168.99.100:8443
  name: minikube

So here you'd want to note down 192.168.99.100.

2. Edit .kube/config and change the server of the minikube cluster from [ip]:[port] to minikubeCA:[port]. Given the above example I'd want it to now look like:

- cluster:
    certificate-authority: /home/[user]/.minikube/ca.crt
    server: https://minikubeCA:8443    
  name: minikube

3. edit /etc/hosts and add the following line (change the IP if it was different in step 1):

192.168.99.100  minikubeCA

Both Click and kubectl work fine for me with this change. Not ideal, but the best I can do for now.

[SanFranciscoSunrise]

oooo, it works! Of all the "workarounds" I have ever seen this one is actually very straightforward, simple, and seems to make sense. Just wish the error messages from rust were more helpful. Maybe there is at least some way to make the error message more obvious/helpful? Anyway, thank you for the explicit instructions. Much appreciated.

[nicklan]

Re-opening so others see this when hitting the issue.

I can actually work around this too, although it's gross, so I'm leaving this open as a tracker for when I push a fix.

[henres]

I seem to have a similar error, but from a gke context on a solus distro :

$ RUST_BACKTRACE=1 click
[none] [none] [none] > context gke_isf-kariba-sandbox_europe-west1-b_pimv2-sandbox
thread 'main' panicked at 'called `Result::unwrap()` on an `Err` value: ()', src/libcore/result.rs:997:5
stack backtrace:
   0: std::sys::unix::backtrace::tracing::imp::unwind_backtrace
             at src/libstd/sys/unix/backtrace/tracing/gcc_s.rs:39
   1: std::sys_common::backtrace::_print
             at src/libstd/sys_common/backtrace.rs:70
   2: std::panicking::default_hook::{{closure}}
             at src/libstd/sys_common/backtrace.rs:58
             at src/libstd/panicking.rs:200
   3: std::panicking::default_hook
             at src/libstd/panicking.rs:215
   4: std::panicking::rust_panic_with_hook
             at src/libstd/panicking.rs:478
   5: std::panicking::continue_panic_fmt
             at src/libstd/panicking.rs:385
   6: rust_begin_unwind
             at src/libstd/panicking.rs:312
   7: core::panicking::panic_fmt
             at src/libcore/panicking.rs:85
   8: core::result::unwrap_failed
   9: click::certs::try_ip_to_name
  10: click::kube::Kluster::new
  11: click::config::kube::Config::cluster_for_context
  12: click::Env::set_context
  13: <click::cmd::Context as click::cmd::Cmd>::exec
  14: click::main
  15: std::rt::lang_start::{{closure}}
  16: std::panicking::try::do_call
             at src/libstd/rt.rs:49
             at src/libstd/panicking.rs:297
  17: __rust_maybe_catch_panic
             at src/libpanic_unwind/lib.rs:87
  18: std::rt::lang_start_internal
             at src/libstd/panicking.rs:276
             at src/libstd/panic.rs:388
             at src/libstd/rt.rs:48
  19: main
  20: __libc_start_main
  21: _start
             at ../sysdeps/x86_64/start.S:120

[nicklan]

This is fixed by #110 and published in 0.4.1. The fix is a little gross, but it works for now and hopefully webpki will support IpAddress SANs in the not too distant future.