replicatedhq/troubleshoot

`uri` fails to fallback under some circumstances

adamancini opened this issue · 2 comments

adamancini commented

Bug Description

An airgapped machine fails to fall back to the provided spec when it was unable to reach the remote spec:
image

$ ./support-bundle ./default.yaml 
Error: failed to load support bundle from URI "https://raw.githubusercontent.com/replicatedhq/troubleshoot-specs/main/in-cluster/default.yaml": failed to get spec from URL: execute request: Get "https://raw.githubusercontent.com/replicatedhq/troubleshoot-specs/main/in-cluster/default.yaml": dial tcp 185.199.111.133:443: i/o timeout

Expected Behavior

Whenever the uri is unreachable for any reason, it should fail-safe to the spec defined in the YAML. troubleshoot should catch all errors and still try to make a support bundle.

Steps To Reproduce

@cbodonnell may have more context on the circumstances to repro

cbodonnell commented

Steps used to reproduce on GCP VM using https://github.com/replicatedhq/oh-my-replicated gcommands. Network error is a bit different than the above screenshot, which was from an end-customer instance.

  1. Create and SSH to VM - gcreate ubuntu-20 airgap and gssh airgap
  2. Download necessary files while there's still outbound connectivity - support-bundle binary and default spec from https://github.com/replicatedhq/troubleshoot-specs/blob/main/in-cluster/default.yaml
  3. "airgap" the instance - gairgap airgap
  4. Run support-bundle against the downloaded spec: ./support-bundle ./default.yaml
diamonwiggins commented

Looks like this behavior was changed in a recent PR - https://github.com/replicatedhq/troubleshoot/pull/1337/files#diff-c28ffef4b225bef3be6d2d4fcae2ff5326cf2e3a63c8484d8a16162add70e7adR235-R247. Before if retrieving the spec via the URL failed, we'd return *troubleshootv1beta2.SupportBundle, but now its always nil