ability to have a DEP-8 test run a test in a separate full system environment
| Affects | Status | Importance | Assigned to | Milestone | |
|---|---|---|---|---|---|
| Auto Package Testing |
Fix Released
|
High
|
James Hunt | ||
Bug Description
The auto-package-test currently creates a kvm instance and runs the DEP-8 tests for a package within it. This is perfectly fine for the majority of packages however, for boot-related packages this can be a problem since if any of the DEP-8 tests cause the auto-package-test environment to fail, the invoker (jenkins) has to detect that the kvm instance is dead after some (probably very long) timeout.
Ideally, there would be a way for a DEP-8 test to specify "run me in a container ('primary container'), but give me access to *another* container ('secondary container') to allow me to run my test(s) in. That way, if any of the tests in 'secondary container' fail (in other words kill 'secondary container'), the DEP-8 test in 'primary container' can handle that gracefully and return a normal failure exit code.
Note that 'secondary container' could either be a nested KVM instance or in fact an entirely separate KVM instance running alongside 'primary container'. LXC is an option but KVM would be preferable since it simulates a full system more fully than LXC which has slightly different semantics.
Examples of packages that could make use of such a facility:
- kernel
- initramfs-tools
- udev
- upstart
- mountall
- plymouth
An example of how this might work for Upstart:
- auto-package-test VM starts
- new version of Upstart package is installed (although not needed in this scenario).
- DEP-8 test runs some new command like:
container-test --packages upstart --timeout 120 --test foo.py --user ubuntu --reboot --log /tmp/foo.log --console /tmp/console.log
- 'container-test' would:
- start a secondary container
- install latest upstart package
- reboot the secondary container to simulate a full boot.
- run foo.py as the named user.
- wait for up to say 2 minutes for the container to shutdown.
- if it fails to shutdown => TEST FAILED.
- if it does shut down, the upstart test could check /tmp/foo.log for some expected output.
- if output as expected => TEST PASSED.
else => TEST FAILED.
Requirements:
- ability for the test in the primary container to:
- have access to the secondary containers console log and or syslog.
- run a program in the secondary container as a specified user from a specified directory.
- boot the secondary container.
- kill the secondary container.
- shutdown the secondary container.
- copy named files from the secondary container to the primary.
Related branches
| Jean-Baptiste Lallement (jibel) wrote | #1 |
| Changed in auto-package-testing: | |
| importance: | Undecided → High |
| status: | New → Confirmed |
| assignee: | nobody → Jean-Baptiste Lallement (jibel) |
| James Hunt (jamesodhunt) wrote | #2 |
| Martin Pitt (pitti) wrote | #3 |
| Changed in auto-package-testing: | |
| assignee: | Jean-Baptiste Lallement (jibel) → Martin Pitt (pitti) |
| status: | Confirmed → In Progress |
| Martin Pitt (pitti) wrote | #4 |
| Martin Pitt (pitti) wrote | #5 |
| Changed in auto-package-testing: | |
| status: | In Progress → Confirmed |
| assignee: | Martin Pitt (pitti) → James Hunt (jamesodhunt) |
| James Hunt (jamesodhunt) wrote | #6 |
| Martin Pitt (pitti) wrote | #7 |
| Changed in auto-package-testing: | |
| status: | Confirmed → Fix Released |
Thanks for your report.
autopkgtest supports 3 types of virtual server regimes:
- null: tests are executed directly on the host
- virt-chroot: use a chroot for isolation
- virt-xenlvm: uses Xen + LVM snapshots
The virt-xenlvm would provide most of the features you describe (I am not sure about reboot) but we have the constraint in the QA Lab to use KVM.
A possible solution would be to implement an additional driver for KVM.