On Fri, Feb 08, 2019 at 11:52:02AM +0100, Cornelia Huck wrote:
> On Thu, 7 Feb 2019 13:00:12 -0500
> Cleber Rosa <cr...@redhat.com> wrote:
>
>
> > diff --git a/tests/acceptance/boot_linux.py b/tests/acceptance/boot_linux.py
> > new file mode 100644
> > index 0000000000..927fac2959
> > --- /dev/null
> > +++ b/tests/acceptance/boot_linux.py
> > @@ -0,0 +1,51 @@
> > +# Functional test that boots a complete Linux system via a cloud image
> > +#
> > +# Copyright (c) 2018-2019 Red Hat, Inc.
> > +#
> > +# Author:
> > +# Cleber Rosa <cr...@redhat.com>
> > +#
> > +# This work is licensed under the terms of the GNU GPL, version 2 or
> > +# later. See the COPYING file in the top-level directory.
> > +
> > +import os
> > +
> > +from avocado_qemu import Test
> > +
> > +from avocado.utils import cloudinit
> > +from avocado.utils import network
> > +from avocado.utils import vmimage
> > +
> > +
> > +class BootLinux(Test):
> > + """
> > + Boots a Linux system, checking for a successful initialization
> > +
> > + :avocado: enable
> > + """
> > +
> > + timeout = 600
> > +
> > + def test_x86_64_pc(self):
> > + """
> > + :avocado: tags=arch:x86_64
> > + :avocado: tags=machine:pc
> > + """
> > + self.vm.set_machine('pc')
> > + self.vm.add_args('-m', '1024')
> > + boot = vmimage.get('fedora', arch='x86_64', version='29',
> > + cache_dir=self.cache_dirs[0],
>
> Somewhat related: I looked at
> https://avocado-framework.readthedocs.io/en/67.0/api/utils/avocado.utils.html#module-avocado.utils.vmimage
> to find out how caching works, but could not find it... does it match
> the checksum?
The "get()" utility function does have a checksum parameter.
https://avocado-framework.readthedocs.io/en/67.0/api/utils/avocado.utils.html#avocado.utils.vmimage.get
And caching is available both with or without a checksum option given.
Now that you've mention this, for this use case, it's desirable to
provide the checksum.
>
> I think we want to make this benign for people on a slow and/or
> data-capped network connection. 'make check-acceptance' downloading
> tons of stuff might come as a bad surprise, and it's probably best to
> avoid doing more of that than strictly necessary.
>
This test can easily take around 10x more the slowest test available
(boot_linux_console.py). So, I'm wondering if it sounds like a good
idea to define some very rough ranges at this point:
* quick: <= 0.5s
* normal (doesn't have to exist as an explicit category, IMO)
* slow: >= 30s
But again, it's hard to come up even with the right times... unless we
had a baseline environment that could be reused by all. Ideas?
- Cleber.
> > + snapshot_dir=self.workdir)
> > + self.vm.add_args('-drive', 'file=%s' % boot.path)
> > +
> > + cloudinit_iso = os.path.join(self.workdir, 'cloudinit.iso')
> > + phone_home_port = network.find_free_port()
> > + cloudinit.iso(cloudinit_iso, self.name,
> > + # QEMU's hard coded usermode router address
> > + phone_home_host='10.0.2.2',
> > + phone_home_port=phone_home_port)
> > + self.vm.add_args('-drive', 'file=%s' % cloudinit_iso)
> > +
> > + self.vm.launch()
> > + self.log.info('VM launched, waiting for boot confirmation from
> > guest')
> > + cloudinit.wait_for_phone_home(('0.0.0.0', phone_home_port),
> > self.name)
