Hi Coiby, thanks for reaching out!
Packit service is using the Testing Farm (TF) project to run tests. TF
itself uses tmt and fmf projects [tmt]. So if you want to run your
tests in the packit workflow, you'd need to make sure they run
correctly with tmt tool itself. I am CCing Petr Splichal and Miro
Vadkerti, the lead developers of tmt and TF projects. Petr is actually
running periodic onboarding sessions where he's helping engineers to
onboard their projects. I'm not sure if TF supports testing VM reboots
right now, I will defer answering that question to the guys.
[tmt]
https://docs.fedoraproject.org/en-US/ci/tmt/#_summary
https://tmt.readthedocs.io/en/stable/
More comments inline.
On Tue, Apr 6, 2021 at 2:39 AM Coiby Xu <coxu(a)redhat.com> wrote:
On Tue, Apr 06, 2021 at 07:36:49AM +0800, Coiby Xu wrote:
>Hi,
>
>I'm adding some kdump tests to dracut to prevent dracut's change from
>breaking kexec-tools [1]. One suggestion is to make use of packit. The
>kdump tests are different from other tests because we need to reboot
>into the second kernel (a dump-capture kernel) to dump the system
>kernel's memory locally fs or to a remote fs (e.g. an nfs fs). Take
>the nfs-kdump test [2] as an example, here are what this test does,
> 1. Build the rpms for dracut and kexec-tools
> 2. Download the Fedora 33 Cloud Base Image
> 3. Start NFS server in a VM
> 4. For the kdump tests done as an NFS client,
> - Install the rpms onto another copy of Fedora 33 Cloud Base Image
> - Start another VM and trigger sysrq to boot into the dump-capture
> kernel to do vmcore dump
> - Check the console output to see if vmcore dump is successful
Petr and Miro, would this workflow work with tmt and TF?
>I'm not sure packit is suitable for these kdump tests. For
example, I
>need to get the path of the rpm built automatically by packit so the
>package can be installed onto the VM image but nowhere can I find
>anything related to that in packit's docs [3] or [4].
We can provide that information via env vars (that would be an RFE for
packit) or you can discover this by querying the RPM database on the
testing system.
When I checked
https://prod.packit.dev/copr-build/96803, I found the
answer, i.e. "dnf copr enable packit/dracutdevs-dracut-1163":)
This is correct, by default packit creates a new COPR project for
every PR using such scheme - you can also build in your own COPR
project if that makes things easier for you.
Then here's another question, can I test against the Atomic Host
test
subject directly? I imagine packit will also start a VM to run the tests.
If we run these kdump tests, nested VMs will be started. Can I eliminate
the nested VMS with the help from packit?
AFAIK we have never tried that. Isn't Atomic Host obsolete at this
point and being replaced by Fedora CoreOS? What's exactly your use
case to test against Atomic Host?
https://www.projectatomic.io/blog/2019/11/fedora-atomic-host-nearing-eol/
Regards,
Tomas
Best regards,
Coiby
_______________________________________________
User-cont-team mailing list
User-cont-team(a)redhat.com
https://listman.redhat.com/mailman/listinfo/user-cont-team