[perccli2] Add perccli2 plugin, PERC H965 and newer controllers

[TrevorBenson]

---

Please place an 'X' inside each '[]' to confirm you adhere to our Contributor Guidelines

• Is the commit message split over multiple lines and hard-wrapped at 72 characters?
• Is the subject and message clear and concise?
• Does the subject start with [plugin_name] if submitting a plugin patch or a [section_name] if part of the core sosreport code?
• Does the commit contain a Signed-off-by: First Lastname [email protected]?
• Are any related Issues or existing PRs properly referenced via a Closes (Issue) or Resolved (PR) line?
• Are all passwords or private data gathered by this PR obfuscated?

[packit-as-a-service]

Congratulations! One of the builds has completed. 🍾

You can install the built RPMs by following these steps:

• sudo yum install -y dnf-plugins-core on RHEL 8
• sudo dnf install -y dnf-plugins-core on Fedora
• dnf copr enable packit/sosreport-sos-3815
• And now you can install the packages.

Please note that the RPMs should be used only in a testing environment.

[arif-ali]

If the code is duplicate, except for the command, is it worth having some test in the original plugin instead, and change the command based on what is found?

[pmoravec]

If the code is duplicate, except for the command, is it worth having some test in the original plugin instead, and change the command based on what is found?

+1

[TrevorBenson]

If the code is duplicate, except for the command, is it worth having some test in the original plugin instead, and change the command based on what is found?

All looks good #3815 (comment)

[TrevorBenson]

If the code is duplicate, except for the command, is it worth having some test in the original plugin instead, and change the command based on what is found?

@pmoravec @arif-ali I originally interpreted this statement as a test for the missing underscore in the filename. Rereading it I suspect it was suggesting:

1. Defining old and new RPM names in a single plugin's packages.
2. Checking if a binary exists, or just making a list cmds, and calling add_cmd_output() as needed.

As perccli2 is not backward-compatible with previous PERC controllers, both RPMs are required to show or manage configurations. Having two generations of controllers on the same host may happen for several reasons.

I checked previous examples of how similar situations were handled, when the RPM and new CLI tool names changed to include a version number grub-<version> & grub-mkconfig vs grub2-<version> & grub2-mkconfig etc.. I based my approach on the grub and grub2 plugins. Is that style choice no longer preferred?

[pmoravec]

Thanks for the explanation. There could be a way of having one plugin even under these circumstances, but I feel until there will be frequent changes to the plugins, having two of them is fine for me.

[TrevorBenson]

Thanks for the explanation. There could be a way of having one plugin even under these circumstances, but I feel until there will be frequent changes to the plugins, having two of them is fine for me.

Then I will leave this branch as is instead of merging the logic into perccli.py. Otherwise, if/when it is preferred to merge them let me know and I will make the necessary adjustments.

[arif-ali]

Thanks for the explanation, and appreciate your patience and understanding in trying to reduce duplication