Add drumbeat blog #1670
Add drumbeat blog #1670
Conversation
|
Fixes #1660 |
| --- | ||
| title: "April Drumbeat: Better Output, Faster Debugging, and More Plugins" | ||
| image: /img/sonobuoy.svg | ||
| excerpt: An update about the recent improvements to Sonobuoy which include more support for sidecars, more debugging information surfaced, and unique new plugins. |
|
|
||
| ## Improved Plugins with Sidecar Containers | ||
|
|
||
| Plugins have been able to have sidecar containers ever since the podSpec was configurable. However, they weren’t able to share in some of the features that Sonobuoy provided to the main plugin container; namely automatic environment variables and config-maps. |
There was a problem hiding this comment.
Should it be "ever since the podSpec was made configurable"?
|
|
||
| Plugins have been able to have sidecar containers ever since the podSpec was configurable. However, they weren’t able to share in some of the features that Sonobuoy provided to the main plugin container; namely automatic environment variables and config-maps. | ||
|
|
||
| Recent changes have made it so that if you have a sidecar container, it will have access to the same environment variables that Sonobuoy adds to the main container (e.g. `SONOBUOY_K8S_VERSION`, `SONOBUOY_RESULTS_DIR`, etc). |
There was a problem hiding this comment.
Would it be worthwhile to give an example of why this would be useful or will this be obvious to devs?
There was a problem hiding this comment.
I think its fairly obvious that you may want those in certain circumstances but then 2 lines later makes it explicit: This allows you to have complex, configurable behavior in both the main container and the sidecar.
|
|
||
| Recent changes have made it so that if you have a sidecar container, it will have access to the same environment variables that Sonobuoy adds to the main container (e.g. `SONOBUOY_K8S_VERSION`, `SONOBUOY_RESULTS_DIR`, etc). | ||
|
|
||
| In addition, the config-maps specified in the plugin definition will also be mounted in the sidecar containers at the same location (`SONOBUOY_CONFIG_DIR`). This allows you to have complex, configurable behavior in both the main container and the sidecar. |
There was a problem hiding this comment.
Same question, would an example of "complex, configurable behavior" help folks better understand?
There was a problem hiding this comment.
:) I can give a more concrete example, no problem.
|
|
||
| ## More Debug Information Surfaced from Results | ||
|
|
||
| The Sonobuoy results tarball has lots of useful information in it to help debug problems. However, its a pain to have to dig through the large number of files to find simple pieces of information. |
|
|
||
| There are clearly lots of errors and warnings in the control-plane logs, but if you are trying to trace down errors it can be helpful to see if there are an increased number in a particular file. | ||
|
|
||
| The error/warning detection checks for basic string patterns and may be extended or configurable in the future. |
There was a problem hiding this comment.
Maybe tweak slightly? Just to clarify a few vague parts.
The error/warning detection currently checks for basic string patterns only, but this functionality may be extended or made more configurable in the future.
|
|
||
| As part of [strategy][strategy] we are continuing to develop additional plugins that can be utilized by the community. We wanted to mention two that are currently in development which we hope will find broad support. | ||
|
|
||
| ### Sonolark |
There was a problem hiding this comment.
I love this name! It is so melodious!
|
|
||
| ### Sonolark | ||
|
|
||
| [Sonolark][sonolark] is a plugin that allows you script your own business logic without any of the image management that normally goes with maintaining a plugin. It uses the [Starlark][starlark] language as the scripting language which allows you to take advantage of our base images’ library of features and assertions. It provides access to the Kubernetes API, integration with Sonobuoy, and an expanding library of assertion/translation functions. |
There was a problem hiding this comment.
allows you TO script your own...
There was a problem hiding this comment.
Also, comma here: "the scripting language, which"
Also, I think it should be either:
our base image's library
or
our base images' libraries
Or are you saying that there are multiple base images and they all use a single library? Lol, just occurred to me that this is the likely case. In that case, please ignore this last suggestion!
There was a problem hiding this comment.
Nope, you're right. In this context I am saying we maintain THE image (technically it gets versioned so there are more of them, but you only ever use one at a time) and it accesses that image's library...
|
|
||
| [Sonolark][sonolark] is a plugin that allows you script your own business logic without any of the image management that normally goes with maintaining a plugin. It uses the [Starlark][starlark] language as the scripting language which allows you to take advantage of our base images’ library of features and assertions. It provides access to the Kubernetes API, integration with Sonobuoy, and an expanding library of assertion/translation functions. | ||
|
|
||
| This makes a really lightweight solution which can help in numerous situations where you might otherwise simply provide end-users with instructions to follow. In addition, since there is no image management involved, development can be extremely fast since you just tweak the script and have your new plugin ready to use or share. |
There was a problem hiding this comment.
Maybe one sentence example? Something like "For example, you can run a version check or confirm a correct role binding by writing a simple script and then running "sonobuoy blah lbah myscript" from the command line.
|
|
||
| The idea is that internally Sonobuoy uses a YAML format to report results and there are occasions where you may want to make modifications to the data after the fact. This is particularly true when you can’t modify the plugin code directly (e.g. for the upstream Kubernetes E2E plugin). | ||
|
|
||
| By utilizing [ytt][ytt], the user can provide a transform via a config-map and do things like: |
There was a problem hiding this comment.
what kind of transform?
a data transform? Some other technical term?
|
|
||
| By utilizing [ytt][ytt], the user can provide a transform via a config-map and do things like: | ||
|
|
||
| Add additional context to errors such as KB articles |
There was a problem hiding this comment.
I'd tweak this to say:
Add additional context to errors, such as links to relevant KB articles
|
|
||
| Add additional context to errors such as KB articles | ||
| Remove unnecessary tests to make output more readable (e.g. remove those 5,000 skipped tests from the e2e output) | ||
| Automatically tagging or removing tests known to be flaky while they get fixed |
There was a problem hiding this comment.
tag or remove tests (the first two verbs in the list are without ing, so might as well make this parallel)
| Add additional context to errors such as KB articles | ||
| Remove unnecessary tests to make output more readable (e.g. remove those 5,000 skipped tests from the e2e output) | ||
| Automatically tagging or removing tests known to be flaky while they get fixed | ||
| Injecting debugging steps directly into failure messages |
Signed-off-by: John Schnake <jschnake@vmware.com>
|
Thanks for the review @eleanor-millman ! |
Signed-off-by: John Schnake jschnake@vmware.com