Overview
This is a fairly big release with a number of worthwhile improvements and bug fixes that we would recommend users take advantage of, including:
- Simplified results reporting for many plugins
- Better handling of multi-container plugins
- Bug fixes related to results storage and cooperation between components
- A new command to wait on an existing Sonobuoy run
- More os/arch support
- and more
Improvements
Sonobuoy automatically reports results if your plugin completes and exits 0
One of the most frustrating types of bugs is where the plugin container runs successfully but fails to write the done file to inform
the Sonobuoy worker that it has completed and where to find the results.
We decided to add a bit more intelligence to the worker to avoid many of these cases. Now, if the worker container is the only container left
running and the others all exited with a status code of 0, the worker will automtaically upload the entire
results directory to the aggregator on your behalf.
e4f0a0d Sonobuoy workers report results of completed plugins
Add environment variables and mounts to sidecar containers
Now that Sonobuoy adds a few environment variables to the containers it creates (Kuberentes version, directory locations, etc), it is reasonable that we should
be adding these to the sidecars and other containers in the plugin.
9ae72e6 Add all env vars to all containers
Running Sonobuoy without any plugins
Many releases ago it was possible to run Sonobuoy without any plugins as solely a means of gathering the other debug information. This use case was
dropped at some point but we have found that some users relied on it so we are adding it back in a simpler fashion.
If you want to run Sonobuoy but not run any plugins, just add SkipPlugins: true to the Sonobuoy config file (e.g.
sonobuoy gen config then edit the file). This will clear out the plugin selections so that the aggregator has no plugins to load.
8c57b24 Add special config option to skip all plugins
New build artifacts: s390x and ppc64le
Kubectl supports these formats and so should we. Thanks to @barthy1 and @MatthieuSarter for this help.
06f5616 Update build setup to publish sonobuoy binary and image for s390x and ppc64le
Add a new sonobuoy wait command
Sometimes you start a sonobuoy run and then later decide you wish you had provided --wait. We added a convenience command
to effectively do that. Just run sonobuoy wait to wait for the Sonobuoy run in the targeted namespace to complete.
17b7050 Add sonobuoy wait command
Rename plugins on a per-run basis without editing YAML
Now that locally Sonobuoy can install/lookup different plugins and configurations, it is much more
likely that a user may want to run two different configurations of the same plugin at the same time. However,
Sonobuoy requires that plugin names are unique.
To avoid having to edit the YAML each time this may occur, you can edit the plugin name for that individual run by a new
bit of syntactic sugar:
$ sonobuoy run -p <old-name>@<new-name>0434aa0 Allow plugin renaming via @ seperator in flag name
Reworking sonobuoy plugins list output
We are still working out the best approach for some of the plugin management commands. As part of that effort
we've reworked the sonobuoy plugins list output to make it more succinct and to try and make it more clear
how to invoke the plugin from the command line.
a01be9b Clarify plugin list output surrounding name/file
Bug Fixes
Fix bugs involving a custom ResultsDir
A few issues have occurred lately where it became clear that the ResultsDir field of the Sonobuoy
config was not being respected or passed correctly between the different bits of code.
As such, there were situations where the plugin and sonobuoy-worker disagreed about where the results should be stored
or mounted from and other bugs where the CLI client and aggregator pod would disagree about where
the aggregator stored the final product.
9bf47ef Pass ResultsDir through necessary calls
Fixed a bug causing nodeSelectors to not be properly respected
If your daemonset plugin is OS-specific, you'll need to have the nodeSelector set to target the right nodes.
However, Sonobuoy goes beyond the default Kubernetes tracking and will monitor which nodes have or have not yet run
the plugin. It is important that Sonobuoy properly understands the nodeSelector being used or else it will constantly expect
other nodes to report results when none will occur due to the scheduling limitation.
4b072ef Fix plugin nodeSelector issue inc. systemd-logs
Fixed a bug causing some pod logs to be dropped
Fixed a race in sonobuoy logs that sometimes caused logs from random containers to not be gathered.
Also added a new special case to get just the logs from the Sonobuoy aggregator pod:
$ sonobuoy logs -p sonobuoy95eb1e2 Fix logs bug causing aggregator to be dropped
Full Changelog
dc78b39 Bump version for v0.55.0
f7f9a6f Add flag for specifying the aggregator path to retrieve
8c57b24 Add special config option to skip all plugins
d043d72 Fix bug causing some duplicate gojson tests
9ae72e6 Add all env vars to all containers
e4f0a0d Sonobuoy workers report results of completed plugins
e31cd28 Upload artifacts from integration tests
9bf47ef Pass ResultsDir through necessary calls
bfcbf9b Remove deprecated fields
9109c69 Fix build image push issue
c6e899d Fix issues related to logging and plugin cache
06f5616 Update build setup to publish sonobuoy binary and image for s390x
17b7050 Add sonobuoy wait command
4b072ef Fix plugin nodeSelector issue inc. systemd-logs
95eb1e2 Fix logs bug causing aggregator to be dropped
582ac8a Update GoReleaser config for linux-ppc64le
51f037b Update build script to build ppc64le binary and image
f6ed823 Bump version of systemd-logs
0434aa0 Allow plugin renaming via @ seperator in flag name
a01be9b Clarify plugin list output surrounding name/file
1ca5b4e Add plugin management blog