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

Rerun command #634

Closed
stevesloka opened this issue Mar 15, 2019 · 3 comments
Closed

Rerun command #634

stevesloka opened this issue Mar 15, 2019 · 3 comments
Labels
lifecycle/consideration Requires discussion before advancing lifecycle/needs-product Needs PM attention p3-low

Comments

@stevesloka
Copy link
Contributor

Describe the solution you'd like
Today if I execute a run against a cluster, to run the same thing again I have to delete and start over. Would be neat to maybe say sonobuoy rerun and it would run the same job that just happened with the same configuration (i.e. custom plugins, etc).

@lovejoy
Copy link

lovejoy commented Mar 21, 2019

kubectl -n heptio-sonobuoy get pod sonobuoy -o yaml > sonobuoy.yaml
kubectl -n heptio-sonobuoy delete -f sonobuoy.yaml
kubectl -n heptio-sonobuoy create -f sonobuoy.yaml

@johnSchnake johnSchnake added lifecycle/needs-product Needs PM attention lifecycle/consideration Requires discussion before advancing labels Apr 3, 2019
@johnSchnake
Copy link
Contributor

I just made #701 which listed this as just one potential use case.

Also, fwiw, I exec'd into the Sonobuoy pod running master and manually kicked off another run (e.g. sonobuoy master) for some testing purpose and was pleasently surprised at how well things worked.

It seemed to run all the plugins and gather results without conflicts and because the results tarball is timestamped, even though the config.json UUID was the same, the filenames did not conflict.

In addition, when running sonobuoy retrieve from my client, it downloaded both files and echo'd them to stdout as expected. So in this way you could script around something like this in a useful way by just iterating over the output from or passing it to xargs.

@johnSchnake
Copy link
Contributor

Same as #701; closing since we've made the conscious effort to avoid the server from responding to requests mid-run since that adds a large number of security questions/problems.

Sign up for free to join this conversation on GitHub. Already have an account? Sign in to comment
Labels
lifecycle/consideration Requires discussion before advancing lifecycle/needs-product Needs PM attention p3-low
Projects
None yet
Development

No branches or pull requests

3 participants