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

Implicitly extract tar.gz files from plugins that upload them #47

Merged
merged 1 commit into from
Aug 10, 2017

Conversation

kensimon
Copy link

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

@kensimon
Copy link
Author

Fixes #28

@kensimon kensimon force-pushed the extract-tar-within-tar branch from 5ef704b to 263664a Compare August 10, 2017 01:34
Copy link
Contributor

@timothysc timothysc left a 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.

if result.Extension != "" {
extension = result.Extension
} else {
extension = result.GuessExtension()
Copy link
Contributor

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?

Copy link
Author

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?

@@ -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()
Copy link
Contributor

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?

Copy link
Author

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.

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
Copy link
Contributor

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?

Copy link
Author

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) {
Copy link
Contributor

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
Copy link
Contributor

Choose a reason for hiding this comment

The reason will be displayed to describe this comment to others. Learn more.

Copy link
Author

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>
@kensimon kensimon force-pushed the extract-tar-within-tar branch from 263664a to 5082fc2 Compare August 10, 2017 17:52
@kensimon
Copy link
Author

@timothysc PTAL

Made some changes per review:

  • If there's no file extension in the upload URI, we just save the file without an extension instead of guessing one (so no untarring will happen in that case)
  • Plugin errors channeled from driver.Monitor() now carry a ".json" extension to make things consistent, and there's a test for this now
  • Removed duplicate Close() calls by putting the file write in a closure and putting the defer f.Close() there

Copy link
Contributor

@timothysc timothysc left a 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
Copy link
Contributor

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.

Copy link
Author

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.

@kensimon kensimon merged commit 7aac273 into vmware-tanzu:master Aug 10, 2017
jhamilton1 pushed a commit to jhamilton1/sonobuoy that referenced this pull request Jun 27, 2018
Implicitly extract tar.gz files from plugins that upload them
Signed-off-by: Jesse Hamilton jesse.hamilton@heptio.com
jhamilton1 pushed a commit to jhamilton1/sonobuoy that referenced this pull request Jun 27, 2018
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
Sign up for free to join this conversation on GitHub. Already have an account? Sign in to comment
Labels
None yet
Projects
None yet
Development

Successfully merging this pull request may close these issues.

2 participants