search

replicatedhq / troubleshoot

Preflight Checks and Support Bundles Framework for Kubernetes Applications
https://troubleshoot.sh
Apache License 2.0
545 stars 93 forks source link

Upload results direct to Vendor Portal #1154

Closed xavpaice closed 4 months ago

xavpaice commented 1 year ago

Describe the rationale for the suggested feature.

When an end customer generates a support bundle using the CLI, the resulting tarball needs to be manually sent to the vendor, who then manually uploads that to Vendor Portal so it can be associated with a support case. This is very time consuming, and frustrating for all involved.

KOTS recently grew a beta feature to automatically upload the bundle on creation, but that does not alert the Vendor that the bundle was uploaded and so has not yet been announced as GA.

We would like to have similar functionality for the support-bundle CLI.

Describe the feature

During application install, add an item in the support-bundle spec secret stored in-cluster, that provides enough data from the license to identify the customer when a bundle is uploaded. This information is translated to a customer-specific URI which points at a Vendor Portal endpoint, specific to that license.

On running support-bundle, presence of the URI for upload triggers the binary to attempt to upload the resulting tarball to Vendor Portal.

Upload should be enabled by default, and disabled with a CLI switch --disable-upload.

Optionally, if the URI is missing from the spec (e.g. a host collector spec, or one running prior to installation), an --upload-to switch could be used to provide the URI.

Describe alternatives you've considered

Additional context

Likely that there's demand for the results (json) of preflight checks to be uploaded in a similar way.

xavpaice commented 1 year ago

Note: currently, preflight saves it's results in KOTS:

  namespace: 'pavansokkenagaraj'
  uploadResultsTo: https://kotsadm-web-pavansokkenagaraj.okteto.repldev.com/api/v1/preflight/app/qakots/sequence/0
vsklevko commented 1 year ago

@xavpaice give that is store the results in KOTS, I believe the best possible solution is going to be an introduction of a custom pod that listens for any new SB within KOTS Admin and then wraps the necessary logic to call whatever GitHub API necessary to create an issue?

To me the above sounds like a viable solution.

chris-sanders commented 1 year ago

GitHub API's aren't used to create issues at Replicated, Vendor Portal is.

Putting that aside, troubleshoot's not meant to (currently) require presence in cluster like a pod to accomplish it's features. I can't think of any advantage to a pod persistently running instead of putting the same logic in the binary to begin with. Am I missing something?