NMS-16953: Correct the WinRM Virtual Memory graph

[dino2gnt]

Add corrected graph as a new file and suppress the incorrect graph to avoid creating an rpmnew on upgrades

See #7110 for previous version of this PR.

All Contributors

• Have you read our Contribution Guidelines?
• Have you (electronically) signed the OpenNMS Contributor Agreement?

Contribution Checklist

• Please make an issue in the OpenNMS issue tracker if there isn't one already.
  Once there is an issue, please:
  1. update the title of this PR to be in the format: ${JIRA-ISSUE-NUMBER}: subject of pull request
  2. update the Jira link at the bottom of this comment to refer to the real issue number
  3. prefix your commit messages with the issue number, if possible
  4. once you've created this PR, please link to it in a comment in the Jira issue
     Don't worry if this sounds like a lot, we can help you get things set up properly.
• If this code is likely to affect the UI, did you name your branch with -smoke in it to trigger smoke tests?
• If this is a new or updated feature, is there documentation for the new behavior?
• If this is new code, are there unit and/or integration tests?
• If this PR targets a foundation-* branch, does it try to avoid changing files in $OPENNMS_HOME/etc/?

What's Next?

A PR should be assigned at least 2 reviewers. If you know that someone would be a good person to review your code, feel free to add them.

If you need help making additions or changes to the documentation related to your changes, please let us know.

In any case, if anything is unclear or you want help getting your PR ready for merge, please don't hesitate to say something in the comments here,
or in the #opennms-development chat channel.

Once reviewer(s) accept the PR and the branch passes continuous integration, the PR is eligible for merge.

At that time, if you have commit access (are an OpenNMS Group employee or a member of the OGP) you are welcome to merge the PR when you're ready.
Otherwise, a reviewer can merge it for you.

Thanks for taking time to contribute!

External References

• Jira (Issue Tracker): https://opennms.atlassian.net/browse/NMS-16953

[marshallmassengill]

LGTM!

[cgorantla]

This will render two graphs, one would be right one and other broken with the same name as Virtual Memory Usage (WinRM).

Is that desirable ?

[dino2gnt]

This will render two graphs, one would be right one and other broken with the same name as Virtual Memory Usage (WinRM).

Is that desirable ?

It shouldn't. The suppress value should hide the incorrect graph if the correct graph can be rendered instead.

[indigo423]

This will render two graphs, one would be right one and other broken with the same name as Virtual Memory Usage (WinRM).
Is that desirable ?

It shouldn't. The suppress value should hide the incorrect graph if the correct graph can be rendered instead.

1. Why do we want to maintain an incorrect graph?

2. I would always vote for tracking JIRA issues with setting fix versions to generate correct changelogs. My previous job background running OpenNMS systems for customers gives me a strong empathy for people relying on changelogs. Having changes bypassing the changelog, decreases a) transparency and b) trustworthiness and usefulness of the changelog. Besides that, we need to maintain a lot of versions in different GitHub repos, which makes it extremely hard to track changes down when they are merged without JIRA issues.

[dino2gnt]

1. Why do we want to maintain an incorrect graph?

This method allows us to avoid configuration changes / rpmnew files on upgrade, while fixing the graph in all supported branches. It's just a memory graph, but it's wrong, and providing incorrect data to the user is a cardinal sin.

[indigo423]

1. Why do we want to maintain an incorrect graph?

This method allows us to avoid configuration changes / rpmnew files on upgrade, while fixing the graph in all supported branches. It's just a memory graph, but it's wrong, and providing incorrect data to the user is a cardinal sin.

Ok got it, what about removing the wrong graph in develop for H34, that we have a path forward to get rid of it :)

[indigo423]

We need more freak bytes :)

[dino2gnt]

Ok got it, what about removing the wrong graph in develop for H34, that we have a path forward to get rid of it :)

Sure, I can submit a PR for that.

[dino2gnt]

what about removing the wrong graph in develop for H34, that we have a path forward to get rid of it :)

#7552

[cgorantla]

lgtm!

resolved