feat: support for ostree systems

[richm]

Feature: Allow running and testing the role with ostree managed nodes.

Reason: We have users who want to use the role to manage ostree
systems.

Result: Users can use the role to manage ostree managed nodes.
Signed-off-by: Rich Megginson [email protected]

[richm]

@sergio-correia looks like we need to amend the testing-farm test - we need to install the collections from meta/collection-requirements.yml using ansible-galaxy collection install -vv -r meta/collection-requirements.yml before running the tests - not sure where to plug that into packit-ci.fmf

[sergio-correia]

@sergio-correia looks like we need to amend the testing-farm test - we need to install the collections from meta/collection-requirements.yml using ansible-galaxy collection install -vv -r meta/collection-requirements.yml before running the tests - not sure where to plug that into packit-ci.fmf

@kkaarreell: would you know how to handle this?

[kkaarreell]

No idea. What are the expectations? Do we want to test against the actual ostree system or just use a compatible package manager on Testing Farm while keep running against ordinary distro?
Also, any guidance on how to securely install Ansible Galaxy bits?

EDIT: Just found that ansible-galaxy is included in ansible-core. I will take a look at it. Still, my first question stands.

[kkaarreell]

/packit test

[packit-as-a-service]

Account kkaarreell has no write access nor is author of PR!

[kkaarreell]

I have updated tests in RedHat-SP-Security/keylime_server-role-tests#27 , you can rerun tests with a comment "/packit test". Also, see #25.

[sergio-correia]

/packit test

[kkaarreell]

The test has failed with

TASK [rhel-system-roles.keylime_server : Ensure required packages are installed] ***

fatal: [172.18.0.4]: FAILED! => {"changed": false, "msg": "Failed to download packages: python3-mako-1.1.4-6.el9.noarch: Cannot download, all mirrors were already tried without success", "results": []}

Could that be a problem with the code?

[sergio-correia]

The test has failed with

TASK [rhel-system-roles.keylime_server : Ensure required packages are installed] ***

fatal: [172.18.0.4]: FAILED! => {"changed": false, "msg": "Failed to download packages: python3-mako-1.1.4-6.el9.noarch: Cannot download, all mirrors were already tried without success", "results": []}

Could that be a problem with the code?

From the error message, it looks like a network/repo/compose issue.

[richm]

No idea. What are the expectations? Do we want to test against the actual ostree system or just use a compatible package manager on Testing Farm while keep running against ordinary distro?

In order to test against an ostree system, you would need to be able to build and boot an ostree image in testing farm. I don't think that is possible.

So for now, we just want to run tests against the ordinary distro, and when we do downstream testing, we can use our test framework to build and boot an ostree qcow2 image.

Also, any guidance on how to securely install Ansible Galaxy bits?

Not sure what you mean.

EDIT: Just found that ansible-galaxy is included in ansible-core. I will take a look at it. Still, my first question stands.

[kkaarreell]

From the error message, it looks like a network/repo/compose issue.

Yes. But I am not able to reproduce this issue locally. My belief is that the error appears on the managed host, which is a C9S container. I can see all the repositories in the test log and I can download the very same image. And everything works. This time the problem is with a different package, so probably this is indeed a networking issue. I will add more verbosity to the ansible-playbook command.

[kkaarreell]

I have a reproducer and I believe the test failure is related to a broken DNS resolution in podman network on that particular virtual test system. Maybe something related to its configuration as I am not able to reproduce it on a different system. I will follow up with the admin. Anyway, to move this forward I would recommend to merge the other PR with CI config adjustments and then rebase this PR on top of it. That should resolve the issue, I believe.

[richm]

I have a reproducer and I believe the test failure is related to a broken DNS resolution in podman network on that particular virtual test system. Maybe something related to its configuration as I am not able to reproduce it on a different system. I will follow up with the admin. Anyway, to move this forward I would recommend to merge the other PR with CI config adjustments and then rebase this PR on top of it. That should resolve the issue, I believe.

+1 - easier for me to rebase my PR

[richm]

I have a reproducer and I believe the test failure is related to a broken DNS resolution in podman network on that particular virtual test system. Maybe something related to its configuration as I am not able to reproduce it on a different system. I will follow up with the admin. Anyway, to move this forward I would recommend to merge the other PR with CI config adjustments and then rebase this PR on top of it. That should resolve the issue, I believe.

@kkaarreell any updates?

[kkaarreell]

Podman folks are looking into it right now, I do not have futher updates. Can we merge PR#25 to avoid it?