Make package installation for iptables and nftables mutually exclusive

[teacup-on-rockingchair]

Description:

• Make package installation rules for iptables and nftables mutually exclusive

Rationale:

• nftables related rule rely on nftables package being installed, same is valid for iptables related rules, but the package_installed rules do not reflect the conflict between the two approaches so remediation of one package_installed_ rule breaks the other dependant rules and vice versa

Review Hints:

• Review hints here. Replace this text. Don't use the italics format!

• Use this optional section to give any relevant information which could help the reviewer to more quickly and assertively understand and test the changes.

• Good examples are useful commands, if it is better to review all commits together or in a suggested sequence, any relevant discussion in other PRs or issues, etc.

[openshift-ci]

Skipping CI for Draft Pull Request.
If you want CI signal for your change, please convert it to an actual PR.
You can still manually trigger a test run with /test all

[github-actions]

Start a new ephemeral environment with changes proposed in this pull request:

Fedora Environment

Oracle Linux 8 Environment

[marcusburghardt]

There are valid cases where both packages are installed without problems. The problem is when conflicting services are enabled and this was already treated in the #10812. So I don't think we should create a mutually exclusive condition for iptables and nftables packages. Maybe these rules could be filtered out in the profile level.

[marcusburghardt]

@teacup-on-rockingchair , do you have plans for this PR?

[marcusburghardt]

@teacup-on-rockingchair , do you have plans for this PR?

I believe that using the same approach as in #10812, where the applicability was treated in service level instead of package level, should make this PR good to be merged.

[marcusburghardt]

ping @teacup-on-rockingchair : )

[teacup-on-rockingchair]

ping @teacup-on-rockingchair : )

re :)

I am working on a solution that would use profile interactive variable for this problem.
For now will apply to SLE only , today I think I will be able to publish it at least as a draft I was just having doubts if to use this PR or new one.

[marcusburghardt]

ping @teacup-on-rockingchair : )

re :)

I am working on a solution that would use profile interactive variable for this problem. For now will apply to SLE only , today I think I will be able to publish it at least as a draft I was just having doubts if to use this PR or new one.

Thanks for the update. All fine so. Take your time. :)

Regarding this PR, I believe it is almost ready to be merged with minor changes in the platform, as I mentioned here.

So, maybe it would be still valid to make these minor changes and merge this PR. Then you could open another PR to introduce this interactive variable. What do you think?

[github-actions]

🤖 A k8s content image for this PR is available at:
ghcr.io/complianceascode/k8scontent:11191
This image was built from commit: 77390db

Click here to see how to deploy it

If you alread have Compliance Operator deployed:
utils/build_ds_container.py -i ghcr.io/complianceascode/k8scontent:11191

Otherwise deploy the content and operator together by checking out ComplianceAsCode/compliance-operator and:
CONTENT_IMAGE=ghcr.io/complianceascode/k8scontent:11191 make deploy-local

[codeclimate]

Code Climate has analyzed commit 77390db and detected 0 issues on this pull request.

The test coverage on the diff in this pull request is 100.0% (50% is the threshold).

This pull request will bring the total coverage in the repository to 59.2% (0.0% change).

View more on Code Climate.

[marcusburghardt]

/packit build