[AutoQA] #255: Use Config class to simplify access to configuration options
by fedora-badges
#255: Use Config class to simplify access to configuration options
--------------------+-------------------------------------------------------
Reporter: kparal | Owner:
Type: task | Status: new
Priority: minor | Milestone:
Component: core | Keywords:
--------------------+-------------------------------------------------------
Currently all our libraries and tests use ConfigParser and parse our
configuration files (autoqa.conf, fas.conf, etc) directly. That is not
ideal, it involves many lines of code, converting to correct variable
types (int, bool), handling default values, and so on.
We should create a Python class Config, which is initialized once in the
beginning, and then can be access globally and easily from any other
module. It will handle default values and type conversion centrally in one
place. Also access will be much easier.
PS: We already have autoqa.config module. Maybe we just don't use it?
--
Ticket URL: <https://fedorahosted.org/autoqa/ticket/255>
AutoQA <http://autoqa.fedorahosted.org>
Automated QA project
12 years, 2 months
[AutoQA] #350: Add support for using file proxy
by fedora-badges
#350: Add support for using file proxy
-------------------------+--------------------------------------------------
Reporter: kparal | Owner:
Type: enhancement | Status: new
Priority: minor | Milestone: Future tasks
Component: core | Keywords:
-------------------------+--------------------------------------------------
Currently we allow to cache downloaded RPMs with allow_pkg_cache in
autoqa.conf. That uses our own code in util.py:download().
Tim was talking about using file proxy and it now seems to me as a far
better approach. It can cache more files (like yum metadata, ISO files,
etc). The proxy can run on the same computer or on some local-network
computer. Several computers can share the same proxy. We don't have to
care about storing the files and cleaning up the directories. It means
less code. It's transparent for us.
The task now is to play with some proxy, try whether it works, implement
some support for AutoQA (if required), and document the process of setting
it up (probably in [https://fedoraproject.org/wiki/AutoQA_Development
here]).
--
Ticket URL: <https://fedorahosted.org/autoqa/ticket/350>
AutoQA <http://autoqa.fedorahosted.org>
Automated QA project
12 years, 2 months
[AutoQA] #394: All tests must have their maintainer defined
by fedora-badges
#394: All tests must have their maintainer defined
---------------------+-------------------------
Reporter: kparal | Owner:
Type: task | Status: new
Priority: minor | Milestone: Finger Food
Component: tests | Keywords:
Blocked By: | Blocking:
---------------------+-------------------------
Occasionally we are running into issues with tests for which we are not
sure who to ask help with. Every test should have its "maintainer"
defined. The maintainer is a person who to ask about implementation
details or who to harass about bugs.
Currently the autotest's control file contains AUTHOR="..." line. Maybe we
should use that for maintainer definition (even though it might be a
little misleading). Or maybe we should define and use a MAINTAINER="..."
variable.
The task is:
1. Find the best way where to define each test's maintainer
(AUTHOR/MAINTAINER inside control file, etc).
2. Decide whether we need to check its existence.
3. Find maintainers for every test present inside AutoQA and fill it in
inside the source code.
4. Amend the documentation.
--
Ticket URL: <https://fedorahosted.org/autoqa/ticket/394>
AutoQA <http://autoqa.fedorahosted.org>
Automated QA project
12 years, 2 months
[AutoQA] #390: update rats_install
by fedora-badges
#390: update rats_install
----------------------+-----------------------------------------------------
Reporter: hongqing | Owner: hongqing
Type: task | Status: new
Priority: major | Milestone: Automate installation test plan
Component: core | Keywords:
----------------------+-----------------------------------------------------
rats_install does not work after F14. after investigating in it, The
following things should be updated:[[BR]]
1. install.img is compressed into initrd.img, remove the exist check
2. initrd.img is compressed as XZ compressed file instead of gzip
compressed file, gzip in python has to be replaced
--
Ticket URL: <https://fedorahosted.org/autoqa/ticket/390>
AutoQA <http://autoqa.fedorahosted.org>
Automated QA project
12 years, 2 months
[AutoQA] #338: AutoQATest.version - is it needed?
by fedora-badges
#338: AutoQATest.version - is it needed?
-------------------------+--------------------------------------------------
Reporter: kparal | Owner:
Type: enhancement | Status: new
Priority: trivial | Milestone: Finger Food
Component: tests | Keywords:
-------------------------+--------------------------------------------------
In all our tests we have code like this:
{{{
class rpmlint(AutoQATest):
version = 1 # increment if setup() changes
}}}
The question is - is the ''version'' attribute needed and being used at
all? I have never seen any difference in behavior, the setup() phase is
run every time.
We should have look at autotest documentation or source code whether this
is being used and when. If we don't need it, let's remove it from all our
tests and templates (the less code the better).
--
Ticket URL: <https://fedorahosted.org/autoqa/ticket/338>
AutoQA <http://autoqa.fedorahosted.org>
Automated QA project
12 years, 2 months
[AutoQA] #408: depcheck: Argument list too long
by fedora-badges
#408: depcheck: Argument list too long
---------------------+-------------------------------
Reporter: kparal | Owner:
Type: defect | Status: new
Priority: minor | Milestone: Nice to have soon
Component: tests | Keywords:
Blocked By: | Blocking:
---------------------+-------------------------------
{{{
Traceback (most recent call last):
File "/usr/lib/python2.7/site-packages/autoqa/decorators.py", line 72,
in newf
f_result = f(*args, **kwargs) #call the decorated function
File "/usr/share/autotest/tests/depcheck/depcheck.py", line 174, in
run_once
depcheck_output = utils.system_output(cmd, retain_output=True)
File "/usr/share/autotest/common_lib/base_utils.py", line 931, in
system_output
args=args).stdout
File "/usr/share/autotest/common_lib/base_utils.py", line 654, in run
stderr_level=get_stderr_level(stderr_is_expected)),),
File "/usr/share/autotest/common_lib/base_utils.py", line 79, in
__init__
stdin=stdin)
File "/usr/lib64/python2.7/subprocess.py", line 672, in __init__
errread, errwrite)
File "/usr/lib64/python2.7/subprocess.py", line 1202, in _execute_child
raise child_exception
OSError: [Errno 7] Argument list too long
}}}
http://autoqa-
stg.fedoraproject.org/results/27644-autotest/virt24.qa/depcheck/results/f...
Sometimes we hit system limits.
Proposed solution: Write pending builds to one file, accepted builds to a
different file, then provide these files using different command line
options to depcheck. Place both files in the results directory.
I don't think this issue is really hot, because it happens seldom. Putting
to "nice to have soon".
--
Ticket URL: <https://fedorahosted.org/autoqa/ticket/408>
AutoQA <http://autoqa.fedorahosted.org>
Automated QA project
12 years, 2 months
[AutoQA] #194: Incorporate automated anaconda storage suite
by fedora-badges
#194: Incorporate automated anaconda storage suite
--------------------+-------------------------------------------------------
Reporter: jlaska | Owner:
Type: task | Status: new
Priority: major | Milestone: Automate installation test plan
Component: tests | Version: 1.0
Keywords: |
--------------------+-------------------------------------------------------
Chris Lumens has developed a virt-based test suite to automate different
disk/storage install scenarios. I've discussed this briefly with Chris,
but I'd be interested in seeing his test suite incorporated within autoqa
and run on a regular interval (perhaps along-side Liam's install tests).
The tests are currently available at http://clumens.fedorapeople.org
/anaconda-storage-test/
--
Ticket URL: <https://fedorahosted.org/autoqa/ticket/194>
AutoQA <http://autoqa.fedorahosted.org>
Automated QA project
12 years, 2 months