-
Notifications
You must be signed in to change notification settings - Fork 345
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
Implicitly extract tar.gz files from plugins that upload them #47
Conversation
Fixes #28 |
5ef704b
to
263664a
Compare
There was a problem hiding this comment.
Choose a reason for hiding this comment
The reason will be displayed to describe this comment to others. Learn more.
Comments, namely around us being explicit on the results coming from the plugins.
pkg/plugin/aggregation/aggregator.go
Outdated
if result.Extension != "" { | ||
extension = result.Extension | ||
} else { | ||
extension = result.GuessExtension() |
There was a problem hiding this comment.
Choose a reason for hiding this comment
The reason will be displayed to describe this comment to others. Learn more.
Guess? Aren't we always going to be explicit w/defaults?
There was a problem hiding this comment.
Choose a reason for hiding this comment
The reason will be displayed to describe this comment to others. Learn more.
We only know the extension if one was provided in the upload URI (ie. /api/v1/results/global/foo.json), I'm not introducing any concept of per-plugin defaults or anything.
In case a plugin doesn't include a .
in the upload URI, we're using the old behavior of guessing json
unless it's the e2e plugin. This may be a bit over-defensive though. Any suggestions on a better approach?
pkg/plugin/aggregation/aggregator.go
Outdated
@@ -217,5 +225,20 @@ func (a *Aggregator) handleResult(result *plugin.Result) error { | |||
io.Copy(f, result.Body) | |||
glog.Infof("wrote results to %v\n", resultsFile) | |||
|
|||
// If it's a tarball, extract it | |||
if extension == ".tar.gz" { | |||
f.Close() |
There was a problem hiding this comment.
Choose a reason for hiding this comment
The reason will be displayed to describe this comment to others. Learn more.
shouldn't we close above and remove the defer?
There was a problem hiding this comment.
Choose a reason for hiding this comment
The reason will be displayed to describe this comment to others. Learn more.
Trying to be defensive in case later code introduces things that may panic... Close() is safe to call repeatedly on a filehandle in go, at least from what I've been able to dig up.
I'll make another pass at this and see if I can make it a bit cleaner, I'm not all that happy with it yet.
pkg/plugin/aggregation/aggregator.go
Outdated
err = tarx.Extract(resultsFile, path.Join(a.OutputDir, result.Path()), &tarx.ExtractOptions{}) | ||
if err != nil { | ||
glog.Errorf("Could not extract tar file %v: %v", resultsFile, err) | ||
return err |
There was a problem hiding this comment.
Choose a reason for hiding this comment
The reason will be displayed to describe this comment to others. Learn more.
I'd have to pop up, but what happens if there is an error in the aggregation? Is it just reported and tar.gz the whole results?
There was a problem hiding this comment.
Choose a reason for hiding this comment
The reason will be displayed to describe this comment to others. Learn more.
Good point, currently errors are channeled from (*Driver).Monitor()
as Result
objects and get stored the same way, but nothing's specifying that their extension should be json. I'll add Extension: ".json"
to the MakeErrorResult function here, and make sure we have tests for this.
}) | ||
} | ||
|
||
func TestAggregation_guessExtension(t *testing.T) { |
There was a problem hiding this comment.
Choose a reason for hiding this comment
The reason will be displayed to describe this comment to others. Learn more.
same comment as above.
@@ -212,3 +215,16 @@ func (s *Server) globalResultsHandler(w http.ResponseWriter, r *http.Request) { | |||
s.ResultsCallback(result, w) | |||
r.Body.Close() | |||
} | |||
|
|||
// given an uploaded filename, parse it into its base name and extension. If |
There was a problem hiding this comment.
Choose a reason for hiding this comment
The reason will be displayed to describe this comment to others. Learn more.
Could use https://golang.org/pkg/path/filepath/
There was a problem hiding this comment.
Choose a reason for hiding this comment
The reason will be displayed to describe this comment to others. Learn more.
TIL. But looks like filepath.Ext
grabs the last dot, I want the first dot (eg. I want ".tar.gz" from "e2e.tar.gz", not ".gz".)
This makes it so plugins upload to a path like: ``` /api/v1/results/global/e2e.tar.gz ``` And it will show up in: ``` /results/plugins/e2e/results/<contents> ``` (For single-node plugins, this would map to:) ``` /results/plugins/systemd_logs/node1/<contents> ``` This needs to be documented along with the snapshot documentation that is already under review. Since the upload path is now expected to have a file extension in it, In case for some reason the sonobuoy master launches with an old version of the sonobuoy worker (or for plugins not using `sonobuoy worker` that upload their own contents), if the path has no file extension, it is guessed to be `.json` or `.tar.gz`, same as before. Signed-off-by: Ken Simon <ninkendo@gmail.com>
263664a
to
5082fc2
Compare
@timothysc PTAL Made some changes per review:
|
There was a problem hiding this comment.
Choose a reason for hiding this comment
The reason will be displayed to describe this comment to others. Learn more.
Minor nit but /lgtm - dealers choice on if you want to change now or later.
// Copy the request body into the file | ||
io.Copy(f, result.Body) | ||
glog.Infof("wrote results to %v\n", resultsFile) | ||
// If it's a tarball, extract it |
There was a problem hiding this comment.
Choose a reason for hiding this comment
The reason will be displayed to describe this comment to others. Learn more.
could switch case this as we'll likely have other file options to add.
There was a problem hiding this comment.
Choose a reason for hiding this comment
The reason will be displayed to describe this comment to others. Learn more.
I'm thinking we can cross that bridge when we get there... it's possible we'll want to something more intelligent like some full post-processing logic that lives somewhere else, etc.
Implicitly extract tar.gz files from plugins that upload them Signed-off-by: Jesse Hamilton jesse.hamilton@heptio.com
Implicitly extract tar.gz files from plugins that upload them Signed-off-by: Jesse Hamilton jesse.hamilton@heptio.com Signed-off-by: Jesse Hamilton jesse.hamilton@heptio.com
This makes it so plugins upload to a path like:
And it will show up in:
(For single-node plugins, this would map to:)
This needs to be documented along with the snapshot documentation that
is already under review.
Since the upload path is now expected to have a file extension in it, In
case for some reason the sonobuoy master launches with an old version
of the sonobuoy worker (or for plugins not using
sonobuoy worker
thatupload their own contents), if the path has no file extension, it is
guessed to be
.json
or.tar.gz
, same as before.Signed-off-by: Ken Simon ninkendo@gmail.com