# Interview2: Design a sonobuoy plugin to do something cool

## Goal

Come up with an idea of something sonobuoy or crashd should do, that it doesnt do and show how you'd implement it. i.e. as a plugin or.. whatever.

## Deliverable

- A paragraph on why you think it would be a useful sonobuoy or crashd plugin / extension

- A breif ascii https://asciiflow.com/#/diagram pasted in this markdown of how it would work, w/

- some code snippets, if appropriate, of how you'd extend either repo and/or of how users would use your thingy

### Goal

Provide a visual way for operators to easily identify failures, navigate to relevant logs/docs, and figure out how to fix them

#### Rationale
One of the challenges that I encountered while learning to use sonobuoy was the manual steps needed to get from running tests, to viewing the results. For example, this was my workflow:

sonobuoy run –wait
sonobuoy retrieve
sonobuoy results <gz file name>
tar -xvf <gz file name>
cd into unzipped directory
code .
Look through plugin results or take a look at sonobuoy_results.yaml

There’s a couple shortcuts that I learned, like using `sonobuoy results –extract`, which does the unzipping for me. But that didn’t allow me to view the quick results using sonobuoy results. I also needed to use my own file viewing/browsing mechanism, like Visual Studio Code, in order to navigate through the directory tree and open specific files as needed.

Moreover, I found that `sonobuoy results` was good for providing a brief overview - if everything succeeds, great. But what if there are errors? And errors in the logs? Then I’d need to dig deeper into the actual results anyways.

I wasn’t able to replicate major test failures, but I can imagine the challenge - going through the `sonobuoy_results.yaml`, to figure out which tests failed, and then go on to figuring out which logs to look at, in order to debug. And then googling the failure to figure out what to do.

#### Overview

What sonobuoy does:
- Runs conformance tests on k8s, allows plugins to run additional tests as well
- Aggregates results, and allows user to download tarball with results and logs

What sonobuoy does not do:
- Write and maintain conformance tests (responsibility is with plugin/k8s authors)
- Provide a way of displaying/browsing results in an interactive manner
- Enforce non-destructive nature (trust is on plugin authors)

I believe that the following can help the operator experience:
- Test-specific hints (eg. Links to documentation/specific tests in k8s conformance, if it fails). I’m not sure if this already exists - for successful e2e tests, it just shows the test name and pass/fail/skip status
- Providing a visual mechanism that provides interactive navigation, filtering, visual data display

I took a look at the github issues and k8s slack channel to validate this - it seems like a while back someone asked if there was a way to visualize data as well! https://kubernetes.slack.com/archives/C6L3G051C/p1657562349767639

#### Implementation

##### Test-specfic hints
Hints for each test would be provided plugin/test authors. The existing output for results (results.Item struct) contains the fields name, Status, Metadata, Details, Items. The Details field is type `map[string]interface{}`, so it can contain anything - this could be where plugin authors add additional helpful information (so don’t need a schema change), but also poses a challenge if we want to render it in a visual tool, since we know it is a variable format.

##### GUI

There are several implementations that I’ve considered for the GUI:

1. MVP (to validate if visual display format is feasible/useful)
1. Generate a single static HTML page, that renders data contained within `sonobuoy_results.yaml`
1. Generate visual table in HTML containing test name, colour coded status, and details from YAML (hints, messages, etc)
1. For e2e tests, details sections of failures to be populated with links directly to upstream test code or KB articles. But it would depend on plugins providing that information, which I couldn’t find.

Flow:
`sonobuoy results –-mode=visual-summary` -> results in the output of a single results.html file

Input: results.tar.gz, containing sonobuoy_results.yaml

        +-------------------------------------------------------+
        | sonobuoy results results.tar.gz --mode=visual-summary |
        +-----------------+-------------------------------------+
                          |
                          |
              +-----------v---------+
              |                     |
              |    Sonobuoy CLI     |   Converts YAML into HTML
              |                     |
              +-----------+---------+
                          |
                          v

                 Output: result.html

2. Angular/Clarity design SPA (VMW styling) + sonobuoy as API
1. The GUI could provide functionality for:
- Rendering results in visual format, like the MVP
- Browsing log files with syntax highlighting for errors
- Being able to diff results against previous conformance runs
- Executing sonobuoy commands from a GUI button
- Having additional filtering options like by tag, prefix, etc.
1. The API would provide functionality for:
- Retrieving results from the sonobuoy aggregator
- Providing file data to the SPA
1. The GUI would interact with the API server using REST JSON or gRPC, querying for results (which in turn the API would query the aggregator to fetch results)
2. The API itself would provide endpoints used to display result data in a format that the GUI can render. For example, providing lists of results, files, file contents, etc.
3. What I don’t like about this idea is that as it is, sonobuoy seems to do what it does well. The purpose is straightforward - run tests provided by plugins, and aggregate the result, and provide a lot of logs to help you debug. Having to build out a whole web UI and turning the CLI into an API seems like a lot of complexity without validated benefit, when perhaps that effort can be focused elsewhere.

Flow:
`sonobuoy gui` -> start web server that serves Web UI, acts as API server for GUI

+----------------------------------------+    +------------------------+
|   Running on local machine             |    |  Running in k8s        |
|                                        |    |                        |
|  +-----------+       +--------------+  |    | +-------------------+  |
|  |Angular GUI+------>| Sonobuoy CLI +--+-+--+>|Sonobuoy Aggregator|  |
|  +-----------+       +--------------+  | |  | +-------------------+  |
|                                        | |  |                        |
|    GET /api/v1/results                 | |  |                        |
|                                        | |  |                        |
|                                        | |  |                        |
+----------------------------------------+ |  +------------------------+
                                           |
                                           |

                                 sonobuoy retrieve

3. Visual Studio Code extension
1. Some people use Visual Studio Code to browse the directory tree, and view files with automatic syntax highlighting. So if that functionality already exists in VSC, then it becomes less beneficial to re-implement that within Sonobuoy itself.
2. Building a typescript-based Visual Studio Code extension can allow the sonobuoy CLI to remain lightweight without changes, while supporting a potential workflow that operators may already use
3. The downside is that it would only be available to those that use VSC

Flow:
Download visual studio code extension, open `sonobuoy_results.yaml` using extension to see YAML rendered in visual format

#### Other findings
- Sonobuoy can be installed via brew, but it’s not documented in the README (can make issue/PR). Learned a bunch about how homebrew-core tracks application versions
- Some links in the docs are broken in https://sonobuoy.io/plugins/ (can make issue/PR)
- I wrote a plugin that deletes k8s resources on the cluster (using https://github.com/vmware-tanzu/sonobuoy-plugins/tree/main/examples/cmd-runner), and it’s able to do that since it seems like the kubeconfig context is passed directly through to the plugin. The sonobuoy site mentions tests are non-destructive, but it really depends on the plugin author!