[Plugin] Add missing DebianPlugins

[jcastill]

There are some missing DebianPlugin imports
in a number of plugins, that causes errors like
this one:

a non-existing plugin (ansible) was specified
in the command line.

When running these plugins.

---

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?

[jcastill]

Draft PR to start the conversation. I'm still testing the missing plugins.
@pmoravec do you think I should rework #3485 or leave that one as it is, and continue in this one with the rest? To separate that one from the issue raised yesterday to the follow up work.

@arif-ali @dnegreira since this affects Debian/Ubuntu, I'd like to have your opinions as well obviously :)

[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-3487
• And now you can install the packages.

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

[jcastill]

Some doubts/questions:

Does it make sense to move some of these changes to use IndependentPlugin?

From the list of failed plugins, these are the ones I doubt if they should be gathered in Debian, mostly because I'm not sure if they are actually available natively:

				crio - no package for debian?
				juju - can be installed via snap?
				landscape - same, via snap?
				lilo - didn't find via apt-get
				maas - only available via snap?
				microk8s - only available via snap?
				unity - only available as snap?
				vault - not available via apt-get

What about the following openstack ones?
openstack_designate
openstack_masakarimonitors
openstack_masakari

Finally, the Ubuntu plugin - I guess we don't need to run this one in Debian.

[TurboTurtle]

Plugins are generally enabled for the distros they make sense for based on feedback from end users and contributing authors. If there are plugins where a particular distribution's tagging class is missing, it is most likely because it has never been requested, which usually implies that the package/component the plugin collects for is not widely used within that distribution's user base and/or the distribution maintainer's or corporate backing entity doesn't want to provide support for it.

IndependentPlugin is for when a plugin can be expected to run on all distributions and without distribution-specific behavior.

[arif-ali]

From the list of failed plugins, these are the ones I doubt if they should be gathered in Debian, mostly because I'm not sure if they are actually available natively:

• juju This is only really available as a snap.
• landscape - is not a snap for the server, there is both deb packages and snap for the client. However doesn't make sense to enable it for Debian
• lilo -- when was the last time this was used. We have packages for Ubuntu, so keep for that, not sure about debian
• maas -- This is available as a deb package as well as snap. The deb package is typically developed and maintained for Ubuntu and not Debian.
• microk8s -- only available as a snap
• unity -- is a window manager that was originally developed for Ubuntu, and was the default for some time. Now it isn't but is still being developed and in the ubuntu repos. I don't seem to find the same for debian, so I don't think it makes sense to have it for debian
• vault -- I added this as part of something that Canonical provides as part of the charms, and currently only a snap

What about the following openstack ones? openstack_designate openstack_masakarimonitors openstack_masakari

The could be, as Canonical folks, we typically maintain our own packages, and test/collect details on what we think is best from field for Ubuntu. It could be that it would work for Debian too, but can't be 100% sure if that is the case. Ideally, we need someone potentially from debian confirm/deny of any of the details

Finally, the Ubuntu plugin - I guess we don't need to run this one in Debian.

The ubuntu plugin collects some Ubuntu specific items, where the ubuntu-advantage status and logs are collected. It does not make sense to enable this on any other distro

Ultimately, snaps can be installed on any distribution, and would just work. Although through the relevant distro policies the SnapPackageManager is only enabled as part of the MultiPackageManager on the ubuntu distro. So, at the moment, I am not sure if the triggers would even work on any other distro if SnapPackageManager is even enabled.

Ultimately, (at least based on my experience), these plugins have been enabled and updated based on experience on the distros and what we want to collect, and this is kind of what @TurboTurtle has mentioned above. As an example, most of the ubuntu aspects have been improved/added based on the experiences of our Ubuntu/Canonical colleagues over the past year

[dnegreira]

Hey @jcastill really appreciate the tagging, thanks for that.

Plugins are generally enabled for the distros they make sense for based on feedback from end users and contributing authors. If there are plugins where a particular distribution's tagging class is missing, it is most likely because it has never been requested, which usually implies that the package/component the plugin collects for is not widely used within that distribution's user base and/or the distribution maintainer's or corporate backing entity doesn't want to provide support for it.

I agree with this statement from @TurboTurtle , and in IMHO, we shouldn't be adding plugins to distro's unless specifically requested/necessary, so I am not too fond with us enabling plugins at this point.

The other side of this conversation is that currently the Debian package is still in 4.0.2, and hasn't been updated in ages, so even if we enable these plugins, they won´t be usable by the users installing sos from the Debian packages.
We intend to tackle this old package in Debian in the future, but that might take some time until we get there.

[jcastill]

Ack, will close this then. Good to know about this policy.