[openstack_edpm] Collect /var/lib/openstack on EDPM nodes

[rabi]

Collect the new EDPM OpenStack layout from /var/lib/openstack while excluding certs, cacerts, and ssh-privatekey data. Keep legacy pre-FR5 collection paths for backward compatibility.

Closes: OSPRH-30140

---

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@example.com?
• 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 dnf install -y 'dnf*-command(copr)'
• dnf copr enable packit/sosreport-sos-4328
• And now you can install the packages.

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

[pmoravec]

So far we have followed the never-written-approach "each .py file in sos/report/plugins stands for a dedicated plugin" - that is broken by the openstack_common.py. I understand the rationale here, just unsure if it cant have some consequences.

Can't this break e.g. sos report -l or sos help sos.report.plugins or similar?

[rabi]

Can't this break e.g. sos report -l or sos help sos.report.plugins or similar?

I don't see any issue with those commands; openstack_common is not being shown as a plugin. That said, if we don't want to create this kind of aberration from the unwritten convention, and are okay with a bit of duplication, I can change it. Let me know.

[pmoravec]

Indeed, both plugins list and help subcommands work well.

IMHO code duplication is yet bit worse than this approach (that I see as not ideal but acceptable). Potential better ideas:

• have the mask_openstack_ini_secrets method declared in openstack_edpm.py and include it from openstack_nova.py (or vice versa)
• comment in code in the openstack_common.py that there is no plugin definition, just an auxiliary method for other Openstack classes

[TurboTurtle]

I'm not onboard with having a non-plugin in report.plugins.

This could, perhaps, be made a more generic postproc_ini_keys() (or whatever) as part of the base Plugin class however? And then any Plugin could call self.postproc_init_keys([list_of_keys]) as part of their postproc().

ini-style files are not exactly uncommon, and I image there are other plugins today that could potentially use something like this.

[rabi]

I'm not onboard with having a non-plugin in report.plugins.

I had checked the loader behavior and this does not break plugin discovery or help/list output. I don't think a generic base Plugin interface as you suggested is a clear fit here, since the masking is still fairly OpenStack-specific and a simple postproc_ini_keys() interface would not cover the connection-URL masking part; if that still has to be handled in the plugins by overriding, we are not really reducing duplication. If we want to keep report.plugins strictly limited to plugin modules, I can remove openstack_common.py and duplicate the masking logic in the affected OpenStack plugins. Let me know. We need this merged quickly as we're not able to support customers with sosreports.

[pmoravec]

Is the

• have the mask_openstack_ini_secrets method declared in openstack_edpm.py and include it from openstack_nova.py (or vice versa)

idea acceptable for both of you?

[rabi]

Is the

• have the mask_openstack_ini_secrets method declared in openstack_edpm.py and include it from openstack_nova.py (or vice versa)

idea acceptable for both of you?

It would make one plugin module import another plugin module which would create a code-level dependency between peer plugins. If we want to avoid openstack_common.py, I’d rather duplicate the small masking logic in the affected OpenStack plugins.

[rabi]

idea acceptable for both of you?

Folks, let me know how to proceed. If that's what want we want I can do it.

[pmoravec]

Neither option is ideal. So I am suggesting yet another: offload such "code common to multiple plugins but not constituting a plugin per se" to some other place - either to parent sos/report/plugins/__init__.py file, or to sos/utilities.py or to say sos/misc.py.

I am fine with either this "offloading elsewhere" approach, or code duplication, or "import one method from another plugin". Neither is ideal, all those is acceptable to me.

[rabi]

method from another plugin"

I am fine with either this "offloading elsewhere" approach, or code duplication, or "import one method from another plugin". Neither is ideal, all those is acceptable to me.

I duplicated the masking code in the plugins so we can get this merged and unblock customer support. This keeps the plugins self-contained, and I do not think plugin-to-plugin dependencies are a good pattern here. I also do not think sos/utilities.py is the right place for plugin-specific shared functionality. We can revisit a more general approach later if needed.

[TurboTurtle]

I understand in a technical sense what this structure change does, but I don't see the benefit to going with that design pattern versus the much simpler approach that was already present and is used across all other plugins.

If there is a tangible benefit to moving to partials over the existing (and in my opinion cleaner) design, please elaborate.

I'd prefer we solve the issue of not replicating ini-style obfuscation at the onset here, but if there is a pressing need then I don't have a problem with duplicating the postproc() code in two plugins until we get something hammered out otherwise. That said, we're not going to rush through for the sake of it and our long established patterns should be maintained unless and until there is sufficient cause to break that pattern.

[TurboTurtle]

I don't see why we're making this change? We don't actually change anything in openstack_nova, and the postproc() method here is just being put behind a level of indirection for....a reason that I'm not seeing.

[TurboTurtle]

Same here. I don't follow the benefit of moving this to a partial like this.

[rabi]

Well, the main benefit for me was readability rather than a behavioral change. It is still part of postproc(), but using mask_openstack_ini_secrets() makes the intent explicit and keeps the regex details out of the main flow. I also thought it could be a step toward moving this into a more appropriate shared location later. That said, the benefit here is fairly small, and if the preference is to keep the simpler inline style for consistency, I’m fine with that.