mirror of https://github.com/proxmox/mirror_qemu
c0c5a7f18e
It's questionable whether it's necessary to create one brand new pair for each test. It's not questionable that it takes less time and resources to just use the keys available at "tests/keys" that exist for that exact reason. If a location for the public key is not given explicitly, the LinuxTest will now set up the existing pair of keys as the default. This removes the need for a lot of boilerplate code. To avoid the ssh client from erroring on permission issues, a directory with restrictive permissions is created for the private key. This should still be a lot cheaper than creating a new key. Signed-off-by: Cleber Rosa <crosa@redhat.com> Message-Id: <20210203172357.1422425-19-crosa@redhat.com> Reviewed-by: Willian Rampazzo <willianr@redhat.com> Reviewed-by: Marc-André Lureau <marcandre.lureau@redhat.com> [marcandre: fix typos in commit message] Signed-off-by: Cleber Rosa <crosa@redhat.com> |
||
|---|---|---|
| .. | ||
| avocado_qemu | ||
| virtiofs_submounts.py.data | ||
| README.rst | ||
| boot_linux.py | ||
| boot_linux_console.py | ||
| cpu_queries.py | ||
| empty_cpu_model.py | ||
| linux_initrd.py | ||
| linux_ssh_mips_malta.py | ||
| machine_arm_canona1100.py | ||
| machine_arm_integratorcp.py | ||
| machine_arm_n8x0.py | ||
| machine_avr6.py | ||
| machine_m68k_nextcube.py | ||
| machine_microblaze.py | ||
| machine_mips_malta.py | ||
| machine_ppc.py | ||
| machine_rx_gdbsim.py | ||
| machine_s390_ccw_virtio.py | ||
| machine_sparc64_sun4u.py | ||
| machine_sparc_leon3.py | ||
| migration.py | ||
| pc_cpu_hotplug_props.py | ||
| ppc_prep_40p.py | ||
| replay_kernel.py | ||
| reverse_debugging.py | ||
| tesseract_utils.py | ||
| version.py | ||
| virtio-gpu.py | ||
| virtio_check_params.py | ||
| virtio_version.py | ||
| virtiofs_submounts.py | ||
| vnc.py | ||
| x86_cpu_model_versions.py | ||
README.rst
============================================ Acceptance tests using the Avocado Framework ============================================ This directory contains functional tests, also known as acceptance level tests. They're usually higher level, and may interact with external resources and with various guest operating systems. For more information, please refer to ``docs/devel/testing.rst``, section "Acceptance tests using the Avocado Framework".