Hi Tomas,
Thank you for the reply!
On Tue, Apr 06, 2021 at 10:19:51AM +0200, Tomas Tomecek wrote:
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/
Last week I played with tmt to run the shell tests. For kdump tests, an
important question is whether TF supports testing VM reboots. So I wait
for Petr Splichal and Miro Vadkerti's answer.
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.
Are those env vars available now? If so, can you point me to the docs?
> 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.
For now, env vars seems to be a better choice:)
> 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/
I used Atomic Host as an example because it's listed on [1] as one of the
three test subjects and kdump tests are done using a Fedora Cloud Base
Image which is similar to Atomic Host. So I guess packit and the kdump
tests framework share some code on manipulating a VM image and I wonder if
the kdump tests can be done without nested VMs with the help of packit.
[1]
https://docs.fedoraproject.org/en-US/ci/standard-test-roles/
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
>
--
Best regards,
Coiby