Enhancement and fix for containerized pytest

[m-horky]

First commit addresses one test that was being skipped on Fedora images. By including dnf-plugins-core package there as well, we can run it.

Second commit removes the excluded tests on CentOS 9 Stream, as https://bugzilla.redhat.com/show_bug.cgi?id=2167468 is now fixed.

[github-actions]

Coverage (computed on Fedora latest) •

File	Stmts	Miss	Cover	Missing
TOTAL	18065	4405	75%

report-only-changed-files is enabled. No files were changed during this commit :)

Tests	Skipped	Failures	Errors	Time
2620	5 💤	0 ❌	0 🔥	55.958s ⏱️

[ptoscano]

Second commit is a fix for CentOS Stream images. Due to recent changes, podman on Fedora exposes local subscription-manager configuration in the container in the /run/secrets/ directory, making the container detection trigger.

For more context: we debugged this offline, and this was due to the system running the containers having actual files for /etc/pki/entitlement, /etc/yum.repos.d/redhat.repo, and /etc/rhsm, which podman mounts automatically on Fedora because of the symlinks in /usr/share/rhel/secrets/.

Also, the changes in certdirectory.py need a bit more thought, especially because there are many other files/modules that have the same pattern.

In the test suite, SubManFixture already takes care of patching rhsm.config.in_container, which covers the vast majority of the tests. I think it'd be better to do the same patching also in tests that do not use SubManFixture.

The other two commits are OK.

[m-horky]

It is true that SubManFixture patches the in_container detection. However, because the modules are imported before any fixture is invoked, the Config object is already created without the patched function, being created in module scope. I don't see a way to fix this other than how I've done it -- we can only embrace it and make the whole codebase behave like this, possibly using Singletons.

For cases like this, where the objects needs some kind of initialization arguments, we'd need to define a place where they are initiated -- essentially, an equivalent of injectioninit.py, but for singletons. But I feel that is out of the scope. We can either merge this now as-is and start preparing proper solution, or omit the patch and only include the other two commits.

[ptoscano]

For cases like this, where the objects needs some kind of initialization arguments, we'd need to define a place where they are initiated -- essentially, an equivalent of injectioninit.py, but for singletons.

Sounds like our @singleton decorator, but using a small "wrapper singleton" to hold the actual object rather than making the object directly as singleton.

But I feel that is out of the scope. We can either merge this now as-is and start preparing proper solution, or omit the patch and only include the other two commits.

Yeah, this starts to get messy, and will definitely require more thoughts; also, there are more cases of config.Config() objects created as module-level variables, so changing only one makes things inconsistent (well they are already, it would grow the entropy).

Since the case it was supposed to fix is a corner one (running the tests in a c9s container from a Fedora system in which there are actual files of subscription-manager), I'd say to drop that commit for now.

Thanks!

[ptoscano]

Thanks!

(fedora-36 in cockpit seems to fail, however it does not matter, as it seems to be some sort of flakyness)