With defaults coming from config file, via the settings module *when
the Avocado implementation of the settings module is concerned only
with the configuration file*. In this case, we can get the value that
will serve as the option defaults from it.

When the Avocado implementation is the "new settings" module, that
concentrates information about the configuration file and command
line, and defaults are registered ahead of time, this becomes a
no-op.
Signed-off-by: NCleber Rosa <crosa@redhat.com>

PoC for setting option with default from config file [2]
Signed-off-by: NCleber Rosa <crosa@redhat.com>

Avocado has introduced a new settings module implementation, currently
available as "avocado.core.future.settings, but with the goal of
replacing the one at "avocado.core.settings".

If find that the this new implementation is available, we can be
certain that we're dealing with configurations that are dictionaries,
and never and argparse.Namespace instance.

Also, because it will live in the same location as the current one,
and because the change will happen at a given point before a release,
we need to implement some heuristic to check for new or old
implementation.

When using the new implementation, it means that new responsibilities
are needed, and registering the core options is required.  In this
case, the compatibility helpers get_opt()/set_opt() can now be defined
according to the presence of the settings implementation, because that
will guarantee that the opts will be a dictionary or not.
Signed-off-by: NCleber Rosa <crosa@redhat.com>

By using the name of the section and key in the configuration file as
as the option name, we both:

 * Improve consistency Adhere to the standard used by the new Avocado
 * settings module

The other positive aspect of this change is that if users should not
be impacted if using configuration files, given that the section names
and keys did not change, and the option names are pretty much
internal.
Signed-off-by: NCleber Rosa <crosa@redhat.com>

To be consistent with the names on latest Avocado plugin interfaces
and configuration data (which is now a dictionary, and no longer the
result of command line arguments and an argparse.Namespace instance).
Signed-off-by: NCleber Rosa <crosa@redhat.com>

And rely on get_opt/set_opt as compatibility, instead of turning a
dictionary into a Namespace() instance.
Signed-off-by: NCleber Rosa <crosa@redhat.com>

Instead of repeating the values as the default for a given option,
let's just use the first entry for each of the supported values list.
Signed-off-by: NCleber Rosa <crosa@redhat.com>

There are options are not used anywhere else, one (vt_tests) is even
set twice.  Overall, all the needed configurations are already set in
the VirtTestOptionsProcess class and in the command line option
creation (such as the selinux option).
Signed-off-by: NCleber Rosa <crosa@redhat.com>

Avocado 69.0 (LTS) already contains loader.DiscoverMode, so it's safe
to just use it directly here.
Signed-off-by: NCleber Rosa <crosa@redhat.com>

Signed-off-by: NCleber Rosa <crosa@redhat.com>

Signed-off-by: NCleber Rosa <crosa@redhat.com>

utils_config.py: Add missing opts for libvirtd.conf and qemu.conf

v2v: improve construction of output options

Add attr 'port' to Interface class

virttest/cpu.py: Extract variants cpu_types and cpu_types_re

Add the server's ip info when the certificates generated

Add method to handle all boot attributes

Support curl stroage backend

Fix get_conf_obj() to create config obj on non-modular daemon

Signed-off-by: NYingshun Cui <yicui@redhat.com>

For global usage in some cpu test cases
Signed-off-by: NQianqian Zhu <qizhu@redhat.com>

  1. url: <protocol>://[<username>[:<password>]@]<host>/<path>
     protocol: 'http', 'https', 'ftp', or 'ftps'
  2. -blockdev driver=https, url=https://a.b.c.d/image,
     username=xx, password-secret=xx, sslverify=off,readahead=xx,
     timeout=xxx
Signed-off-by: NZhenchao Liu <zhencliu@redhat.com>

cpu: update intel cpu model types

Plug 'vfio-pci' into pcie-root-port instead of pcie.0

Fixup: Handle cpu util failures on non implemented arch

Some of the cpu utils are not implemented yet for certain cpu
arch yet due to which we would encounter below error,
during the vt-bootstrap

    create_host_os_cfg(options)
  File ".../virttest/bootstrap.py", line 355, in create_host_os_cfg
    family = cpu.get_family() if hasattr(cpu, 'get_family') else None
  File ".../avocado/avocado/utils/cpu.py", line 188, in get_family
    raise NotImplementedError
NotImplementedError

Let's handle the same, additionaly populate the vendor
information in the config only if available.
Reported-by: NYanan Fu <yfu@redhat.com>
Signed-off-by: NSatheesh Rajendran <sathnaga@linux.vnet.ibm.com>

Signed-off-by: NWenli Quan <wquan@redhat.com>

Adjust to the modular daemon environment checking change

qcontainer: change EFI pflash path for different OS in aarch64

There is a new method to check if modular daemon is enabled on
local and remote, so update accordingly.
Signed-off-by: NYingshun Cui <yicui@redhat.com>

Add a method to check if modular daemon is enabled

Extend contr target

Cirrus CI: drop editable requirements from GIT based installs

Turns out that the "-e" option is not a requirement for installations
from GIT.  The side effect of having that flag, is that a "python
setup.py develop" ended up being called, which did not create the
necessary directories and caused the failures in the comments:

   # When installing from source, pip tries to install at
   # /usr/local/lib/python3.6/site-packages/ and fails with:
   # [Errno 2] No such file or directory: '/usr/local/lib/python3.6/site-packages/test-easy-install-78.write-test'

Without '-e', a common installation occurs, and that failure is no
longer present.

Reference: https://github.com/avocado-framework/avocado/issues/3462Signed-off-by: NCleber Rosa <crosa@redhat.com>

- Add d dict type attr of Interface
- Update function modify_vm_iface() to support newly added attr
Signed-off-by: NHaijiao Zhao <haizhao@redhat.com>

Add guestinfo cmd

Add vlan into the interface xml definition

add boot option splash-time to boot command line

Signed-off-by: NXueqiang Wei <xuwei@redhat.com>

Improve error report when exception happens before Target initialization

Signed-off-by: NYingshun Cui <yicui@redhat.com>