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

Duplicated plugin name in json status #1001

Closed
johnSchnake opened this issue Nov 18, 2019 · 2 comments · Fixed by #1045
Closed

Duplicated plugin name in json status #1001

johnSchnake opened this issue Nov 18, 2019 · 2 comments · Fixed by #1045
Labels
kind/bug Behavior isn't as expected or intended p1-important
Milestone

Comments

@johnSchnake
Copy link
Contributor

What steps did you take and what happened:
sonobuoy status --json | jq

Should have a list of the plugins and their aggregate data. However, you can see in the output below that it duplicated the plugin and only put the data really into one of them.

{
  "plugins": [
    {
      "plugin": "daemonset-worker",
      "node": "ip-172-31-30-196.us-west-2.compute.internal",
      "status": "complete",
      "result-status": "failed",
      "result-counts": {
        "failed": 12,
        "passed": 32,
        "skipped": 4
      }
    },
    {
      "plugin": "daemonset-worker",
      "node": "ip-172-31-47-230.us-west-2.compute.internal",
      "status": "complete",
      "result-status": "",
      "result-counts": null
    }
  ],

It also didnt list the daemonset-master info (which didnt really run since none of the nodes were schedulable but I would think should be in that list).

FWIW the plugin daemonset-worker was targeting nodes without the master label on them; daemonset-master the opposite.

Sonobuoy v0.16.4

@johnSchnake johnSchnake added the kind/bug Behavior isn't as expected or intended label Nov 18, 2019
@johnSchnake
Copy link
Contributor Author

I just realized that the issue is that the node is being set whereas the plugin itself isn't node specific. So I guess the plugin-node logic is adding 2 values (with no result-counts) and then the postprocessing logic is probably just finding one and adding the count data. Something along those lines.

Will have to check what the original intent was here; I'm not certain whether or not the intent was to have the values in that list being dependent on the node at all. I thought it was a rollup of that plugin across the cluster. TBD

@johnSchnake
Copy link
Contributor Author

Easiest way to see this is to set up a 2 node kind cluster and run

sonobuoy run --plugin systemd-logs --wait
sonobuoy status --json | jq

@johnSchnake johnSchnake added this to the 0.17.1 milestone Dec 10, 2019
johnSchnake added a commit that referenced this issue Dec 13, 2019
The bug would cause only one of the plugin/node values in the
`sonobuoy status --json` output to be updated and it would include
all the results for all nodes.

Instead, we want each plugin/node value in that list to report its
own values for passed/failed.

Fixes #1001

Signed-off-by: John Schnake <jschnake@vmware.com>
Sign up for free to join this conversation on GitHub. Already have an account? Sign in to comment
Labels
kind/bug Behavior isn't as expected or intended p1-important
Projects
None yet
Development

Successfully merging a pull request may close this issue.

1 participant