Skip to content
New issue

Have a question about this project? Sign up for a free GitHub account to open an issue and contact its maintainers and the community.

By clicking “Sign up for GitHub”, you agree to our terms of service and privacy statement. We’ll occasionally send you account related emails.

Already on GitHub? Sign in to your account

Upload results #823

Closed
johnSchnake opened this issue Aug 1, 2019 · 2 comments
Closed

Upload results #823

johnSchnake opened this issue Aug 1, 2019 · 2 comments
Labels

Comments

@johnSchnake
Copy link
Contributor

Describe the solution you'd like
A long-standing request has been to facilitate uploading results after a run automatically.

I'd like a new field to be added to the config.Config object: uploadURL (name is flexible). After a run is completed, if that field is set, Sonobuoy should POST the tarball to that URL.

Anything else you would like to add:

  • I originally thought this approach was limited because I didn't want to get in the business of dealing with auth, but I was recently told about how even S3 buckets can be used since pre-signed URLs can be used and Sonobuoy doesn't have to be told anything about credentials.
  • In order to prevent pre-signed URLs from being required for the entire duration of a run (which may be hours depending on the cluster size and plugin selection), the aggregate server can continue to refresh/watch the config file. That config file comes from a configmap whose changes will get propagated to the server. Users who are concerned about security can limit the amount of time those URLs are in the wild this way.
    • TBD: if not told to block after the run, I assume we dont sit/refresh the config checking for that URL. If we are told to block, I figure we periodically refresh and check for that url and post to it if set. The user, in that case, would still be responsible for cleaning up up sonobuoy manually after that? Or would they be able to also modify whether or not sonobuoy should block?
  • More than one URL could/should be settable. No extra effort to support that.
  • This is a special case of Allow for user ordered operations in aggregator #39 but is, by far, the one that keeps coming up. I feel like this is a feature that users will definitely benefit from, implementing it this way is simple/intuitive, and that we shouldn't wait until we want to prioritize a larger, more general solution to run arbitrary containers after the run.

The point is definitely arguable and I'm curious if anyone strongly disagrees. @stevesloka @zubron ?

@johnSchnake johnSchnake added p1-important lifecycle/consideration Requires discussion before advancing labels Aug 1, 2019
@johnSchnake johnSchnake modified the milestone: v0.15.2 Aug 5, 2019
@stale
Copy link

stale bot commented Nov 4, 2020

There has not been much activity here. We'll be closing this issue if there are no follow-ups within 15 days.

@stale stale bot added the misc/wontfix label Nov 4, 2020
@vladimirvivien
Copy link
Contributor

@wilsonehusin while this sounds tempting, I think we should shelf this for now.

Sign up for free to join this conversation on GitHub. Already have an account? Sign in to comment
Labels
Projects
None yet
Development

No branches or pull requests

2 participants