Is this about the standard-test-rhts test role? I believe that we need a booted VM qemu image in this case. I guess a prerequisite would be to have an inventory script that actually boots a dnf/yum installed system rather than running such tests locally.

Adding a custom inventory script to make that happen would be a first step. It could be incubated in a single test, and then brought into standard-test-roles when ready.

Note the restraint [1] supports rhts-reboot. I am more thinking about solving this by using restraint as the runner of these tests. i.e.

1. These tests would be always run on a VM, running in "classic" environment
2. Ansible would run restraintd on the VM and restaint-client on the host (i.e. use it as harness), rhts-reboot supported

I assume this could be implemented as a new role (standard-test-restraint) which would be use specially for these test cases (we could also add a new tag for these).

This way we would not be reinventing the wheel :)

[1] http://restraint.readthedocs.io/en/latest/index.html

FWIW, the standard-test-rhts role already uses restraint--complete with restraintd and restraint client--to run tests. However, both client and server are run on the system under test (container or VM/local host). Perhaps that can be used as the start of a new role, or perhaps the current rhts role can be modified to split up the configuration of the client and server sides of restraint between the target and control hosts.

But I don't know what "reboots" mean in the context of running tests in containers. And can a service such as restriantd be configured to run as expected in an atomic VM?

And can a service such as restriantd be configured to run as expected in an atomic VM?

And if not, what is our "test subject" and or "test context" for a non Atomic VM? I don't have a good answer here. Some examples:

• Cockpit CI curates its own images based on virt-builder + enable repos + dnf update ... which are then tested.
• Lars Karlitski and Linux System Roles uses their the Cloud images for testing which are qcow2 based but are "yum/dnf" managed.

This is a bit mysterious currently, but that's because we really are targetting Atomic Host with the first round of ported tests. So I agree with Merlin that our first target should be figuring out how to make restraint work on Atomic Host ... and making the reboot tests work there.

Is there any update on this? Is it something still a ways away from working, or is it a short term item now? There are other tests we would like to run that reboot the host during execution. An example are the tests in [1]. It would be nice to be able to use standard-test-roles to run these tests (the only thing preventing it is that some of the tests reboot the host).

[1] https://github.com/projectatomic/atomic-host-tests/tree/master/tests

Hi, I am planning to work on prototyping usage of restraint in all 3 supported environment from next week and I will add this to our sprints. Thanks for all the suggestions and comments, I will keep you informed.

@rasibley Feel free to assign me to this task please

@mvadkert great! I don't have permission, @merlinm can you assign Miro to this task ?

Hi.

We must follow next document. It is official Beaker document:

https://github.com/beaker-project/beaker/blob/develop/documentation/user-guide/task-environment.rst

This document relies on rhts-test-env package. Which is freely available for each distro at:

https://beaker-project.org/yum/harness

If we use some else approach, many functionality will be missing, such as:

./usr/bin/rhts-test-runner.sh:146:    export REBOOTCOUNT=0

I would close this.
And if reboot is necessary do it with help of Ansible.
There is no restraint support, and we do not have plans to add it.
@mvadkert right?

yeah, there is no restraint support planned to STI. People needing reboots should use directly restraint to run the tests or use ansible itself to reboot the machine ...