sysinfo: Revert the removed `--quiet` option to journalctl

* https://github.com/avocado-framework/avocado:
  Plugins: introduce archive result plugin
  Plugins Dispatcher: add configurable execution order support
  Plugins Dispatcher: introduce settings_section()
  Plugins Dispatcher: introduce fully_qualified_name()
  Plugins Dispatcher: introduce plugin_type()
  Plugins Dispatcher: default (sorted) order of execution

The archive (ZIP) feature has no reason for reason for being
a core feature, as it maps nicely to the result plugin interface.

Let's turn that into a proper (and quite simple) plugin.

Also, let's add a functional test for both the archive plugin, and for
the ordered execution configuration using the zip archive for that.
Signed-off-by: NCleber Rosa <crosa@redhat.com>

During revert f1456dc3, which reverted
f658f0e5 the `--quiet` was removed,
but it is suppose to be there. Let's revert that part.
Signed-off-by: NLukáš Doktor <ldoktor@redhat.com>

One some situations, users may need to explicitly set the order in
which plugins run.  This adds support for setting the execution order
of any plugin type by using the configuration file.
Signed-off-by: NCleber Rosa <crosa@redhat.com>

Yet another utility method that returns the configuration setting
name based on the dispatcher plugin type.
Signed-off-by: NCleber Rosa <crosa@redhat.com>

As done with `plugin_type()` let's also add an utility method
that gives the plugin's fully qualified name for a given extension.
Signed-off-by: NCleber Rosa <crosa@redhat.com>

This makes it more clear what an Avocado plugin type means.
Signed-off-by: NCleber Rosa <crosa@redhat.com>

The exact order that plugins are executed has never been explicit and
documented.  Let's use a lexical sort of the entry point name to
determine the execution order.

The entry point name is seen when a user runs `avocado plugins`, and
it's also the name used when registering the plugins (usually in a
`setup.py` file).
Signed-off-by: NCleber Rosa <crosa@redhat.com>

* https://github.com/avocado-framework/avocado:
  Release test plan: run rpmlint on generated RPM packages
  avocado.spec: give a more informative package summary
  avocado/utils/kernel.py: remove executable support
  avocado/core/data_dir.py: remove executable support
  avocado/core/version.py: remove executable support
  avocado/utils/partition.py: remove interpreter
  avocado/utils/software_manager.py: remove direct script executable support

The commit f658f0e5 was a workaround of
the process issue fixed in 56e649ea
Let's use our library again.
Signed-off-by: NLukáš Doktor <ldoktor@redhat.com>

* https://github.com/avocado-framework/avocado:
  avocado.utils.process: execute default int handler

The container name was printed into "debug" log, which made the output
looks odd. Let's use the usual "info" log instead (for the UI).
Signed-off-by: NLukáš Doktor <ldoktor@redhat.com>

The `receive_files` is used to get the results of the execution, but it
was removed in 9d483a36 Let's bring it
back to restore docker plugin functionality.
Signed-off-by: NLukáš Doktor <ldoktor@redhat.com>

* https://github.com/avocado-framework/avocado:
  remote: drop directory change command on remote machine
  fix DockerTestRunner __init__() argument

Simple contrib script to find the Job results directory of a given Job
identified by the Job (partial) ID.

Reference: https://trello.com/c/vrp2F5n4Signed-off-by: NAmador Pahim <apahim@redhat.com>

Now that we don't copy files to remote machines anymore, there's no need
to change the directory before run Avocado remotely. Actually this can
break the execution in systems that does not have the directory already
created, since the init_dir call was dropped as part of the remote files
copy removal.
Signed-off-by: NAmador Pahim <apahim@redhat.com>

Commit 295b8f61 changed attribute
names, but there is one leftover on docker plugin. This commit fixes
it.
Signed-off-by: NAmador Pahim <apahim@redhat.com>

Let's add this step to the release test plan, so that we don't introduce
erorrs and warnings to our built package.
Signed-off-by: NCleber Rosa <crosa@redhat.com>

We're basically repeating the name of the package in the summary,
while we could add a bit more useful information.

This also fixes the following warning spotted by rpmlint:

 W: name-repeated-in-summary C Avocado
Signed-off-by: NCleber Rosa <crosa@redhat.com>

Another instance of a non-executable file with a interpreter set.

This fixes the following errors spotted by rpmlint:

 E: wrong-script-interpreter
 /usr/lib/python2.7/site-packages/avocado/utils/kernel.py /usr/bin/env
 python
 E: non-executable-script
 /usr/lib/python2.7/site-packages/avocado/utils/kernel.py 644
 /usr/bin/env python
Signed-off-by: NCleber Rosa <crosa@redhat.com>

* https://github.com/avocado-framework/avocado:
  remote: don't copy files for remote executions
  remote: improve error handling from remote executions
  remote: create a `DummyLoader` and use it in 'remote'
  refactor the total number of tests probe

Another possibly leftover from a time where an executable
`data_dir.py` made sense.  Let's remove it.

This also fixes the following error spotted by rpmlint:

  E: wrong-script-interpreter
  /usr/lib/python2.7/site-packages/avocado/core/data_dir.py
  /usr/bin/env python
  E: non-executable-script
  /usr/lib/python2.7/site-packages/avocado/core/data_dir.py 644
  /usr/bin/env python
Signed-off-by: NCleber Rosa <crosa@redhat.com>

The `version.py` library has once used by various build scripts, as a
script, to get the version number that was set there.  This has
changed for a some time now, so let's remove the executable support.

This also fixes the following error spotted by rpmlint:

  E: wrong-script-interpreter
  /usr/lib/python2.7/site-packages/avocado/core/version.py
  /usr/bin/env python
  E: non-executable-script
  /usr/lib/python2.7/site-packages/avocado/core/version.py 644
  /usr/bin/env python
Signed-off-by: NCleber Rosa <crosa@redhat.com>

This utilility library file has no business at being executable,
so let's remote the executable interpreter currently set.

This fixes the following two errors spotted by rpmlint:

   E: wrong-script-interpreter
   /usr/lib/python2.7/site-packages/avocado/utils/partition.py
   /usr/bin/env python
   E: non-executable-script
   /usr/lib/python2.7/site-packages/avocado/utils/partition.py 644
   /usr/bin/env python
Signed-off-by: NCleber Rosa <crosa@redhat.com>

Software manager was designed as library, but it includes a simple
command line tool support.  But, besides setting a (non-portable) executable
(`/usr/bin/env python`) it also doesn't have executable bits set.

Let's remove the non-portable executable (`/usr/bin/env python`), and keep
the file without executable bits set.  If users want to run it, they can still
do it through:

 $ python -m avocado.utils.software_manager

Which is actually required in most cases because of the relative imports.
This also resolves the following error pointed out by rpmlint:

 E: non-executable-script
 /usr/lib/python2.7/site-packages/avocado/utils/software_manager.py 644
 /usr/bin/env python
Signed-off-by: NCleber Rosa <crosa@redhat.com>

Currently, if not explicitly disabled, we copy the test files for
remote executions. This approach has a number of issues and does not
cover all the cases.

This patch removes the copy of test/multiplex files for remote
executions, making necessary for the remote instance to have the files
available in the indicated locations.
Signed-off-by: NAmador Pahim <apahim@redhat.com>

A remote job can fail for a number of reasons other than remote access
timeout (the only error handled so far).

This patch makes the job to exit nicely, showing the message from
remote job, in case we cannot parse the json output from the remote job.
Signed-off-by: NAmador Pahim <apahim@redhat.com>

In order to remove the hack used to fake the test_suite inside the job
when a remote execution is in place, this patch creates a new loader
class called DummyLoader, which returns the test suite with test
`SkipTest` and the file path as test name. The goal is to not engage
default test loaders when we are in a remote execution.
Signed-off-by: NAmador Pahim <apahim@redhat.com>

Currently, the Job() is in charge to probe the number of tests. But
depending on the test runner in use, this information can be impossible
to probe before calling the test runner. For example, using the remote
test runner, we have no guarantee that the information used to create
the test_suite (test files, and multiplex files) will be available
locally, where the job is processed.

This patch transfer the probe of the number of tests to the test
runner. Also, the Result class was prepared to accommodate this change,
making the total number of tests configurable by calling
ResultProxy.set_tests_total().
Signed-off-by: NAmador Pahim <apahim@redhat.com>

In order to exit subprocess gracefully, our library overrides the
default SIGINT handler with a custom handler that waits for the
subprocess. Since the default SIGINT handler raises a KeyboardExeption,
which is expected by the caller, and our custom handler does not, this
patch calls the default handler from inside our custom handler, after
the steps required to exit the subprocess gracefully.

Reference: https://trello.com/c/NZPg155xSigned-off-by: NAmador Pahim <apahim@redhat.com>

This attribute is used solely for internal purposes.  Let's make it
private.
Signed-off-by: NCleber Rosa <crosa@redhat.com>

The idfile attribute is nothing more than logdir + 'id'.  Since we've
documented this attribute, let's remove it in an attempt to keep the
job namespace cleaner.
Signed-off-by: NCleber Rosa <crosa@redhat.com>

References to test dir and a never used test_index are Job attributes
that should not really exist.
Signed-off-by: NCleber Rosa <crosa@redhat.com>

The `run()` method is supposed to be the simplified interface for
jobs, that is, they run all phases of a job.  This should allow for
users of job instances to simply run:

   >>> job = avocado.core.job.Job()
   >>> result = job.run()

Of course the other more granular methods can still be used.
Signed-off-by: NCleber Rosa <crosa@redhat.com>

The post_tests phase is intended for the job to run any actions after
the tests are run.
Signed-off-by: NCleber Rosa <crosa@redhat.com>

The run_tests phase is responsible for actually running the test suite
that has been created in the create_test_suite phase.
Signed-off-by: NCleber Rosa <crosa@redhat.com>