[AutoQA] #311: Improve Koji call performance with koji.ClientSession.multiCall
by fedora-badges
#311: Improve Koji call performance with koji.ClientSession.multiCall
-------------------------+--------------------------------------------------
Reporter: kparal | Owner:
Type: enhancement | Status: new
Priority: minor | Milestone: Finger Food
Component: core | Keywords:
-------------------------+--------------------------------------------------
We use koji calls quite extensively in watchers/tests/libraries. Some of
the calls may be sped up substantially by using multicalls (executing
multiple calls at once and waiting for a grouped result). See docstring at
koji.!ClientSession.multiCall:
{{{
Execute a multicall (multiple function calls passed to the server
and executed at the same time, with results being returned in a
batch).
Before calling this method, the self.multicall field must have
been set to True, and then one or more methods must have been called
on
the current session (those method calls will return None). On
executing
the multicall, the self.multicall field will be reset to False
(so subsequent method calls will be executed immediately)
and results will be returned in a list. The list will contain one
element
for each method added to the multicall, in the order it was added to
the multicall.
Each element of the list will be either a one-element list containing
the result of the
method call, or a map containing "faultCode" and "faultString" keys,
describing the
error that occurred during the method call.
}}}
Go through our code and re-write standard Koji calls to multicalls
whenever possible.
--
Ticket URL: <https://fedorahosted.org/autoqa/ticket/311>
AutoQA <http://autoqa.fedorahosted.org>
Automated QA project
12 years, 2 months
[AutoQA] #321: Store test logs for at least a month
by fedora-badges
#321: Store test logs for at least a month
------------------------+---------------------------------------------------
Reporter: kparal | Owner:
Type: task | Status: new
Priority: major | Milestone: Nice to have soon
Component: production | Keywords:
------------------------+---------------------------------------------------
Today is May 3rd and some test output from April 30th is already
inaccessible
(https://admin.fedoraproject.org/updates/zabbix-1.8.5-1.fc15). That is
problematic for package maintainers and also for us when dealing with test
issues. We should aim to store results for at least a month.
James mentioned that log pruning was run every 15 days, but sometimes it
had to run more often, because e.g. some depcheck result logs may take up
to several hundred MBs. James, can you provide links to such logs in order
for us to evaluate that issue? Also, you can provide some disk space
statistics? E.g. how much data we usually generate per week, how much disk
space we have available, etc.
If we can't extend available disk space easily, let's aim for reducing
logs size. Can we do some form of transparent filesystem compression? From
my experience depcheck logs have extremely good compress ratio.
--
Ticket URL: <https://fedorahosted.org/autoqa/ticket/321>
AutoQA <http://autoqa.fedorahosted.org>
Automated QA project
12 years, 4 months
[AutoQA] #182: Write virt management script
by fedora-badges
#182: Write virt management script
----------------------------+-----------------------------------------------
Reporter: kparal | Owner:
Type: task | Status: new
Priority: major | Milestone: Virtualization
Component: infrastructure | Version: 1.0
Keywords: |
----------------------------+-----------------------------------------------
We must write a virt management script that will be able to the basic
tasks for us:
* query for available virt systems that we can use
* switch between "real" disk and a disk snapshot for a virt system
* revert a disk snapshot for a virt system
* perform some command in a virt system - e.g. "yum update" for keeping
it periodically up-to-date
* install/reinstall a virt-system for us with specified distro
* (some more to come?)
We may want to use some pre-defined names syntax to recognize what virt
systems do we have. For example:
{{{
/dev/vg_autoqa/F12_i686_1
/dev/vg_autoqa/F12_i686_1-snap
}}}
--
Ticket URL: <https://fedorahosted.org/autoqa/ticket/182>
AutoQA <http://autoqa.fedorahosted.org>
Automated QA project
12 years, 5 months
[AutoQA] #254: Trasnfer autoqa library to autotest clients
by fedora-badges
#254: Trasnfer autoqa library to autotest clients
-------------------------+--------------------------------------------------
Reporter: kparal | Owner:
Type: enhancement | Status: new
Priority: minor | Milestone:
Component: autotest | Keywords:
-------------------------+--------------------------------------------------
Currently autotest clients do not require autotest package installed,
autotest server transfers all necessary files over rsync. But autotest
clients require autoqa installed (because of our autoqa libraries), which
in turn requires autotest.
This creates quite a lot of confusion where to edit which files when
testing new stuff. It would be much easier if we somehow transferred also
the autoqa library together with autotest files. Can we bend autotest a
little to rsync also our library to the client? Or, can we use similar
approach as copying the config files to the test directory also with
autoqa library? It would be great.
--
Ticket URL: <https://fedorahosted.org/autoqa/ticket/254>
AutoQA <http://autoqa.fedorahosted.org>
Automated QA project
12 years, 5 months
[AutoQA] #196: Log failed job scheduling
by fedora-badges
#196: Log failed job scheduling
-------------------------+--------------------------------------------------
Reporter: kparal | Owner: kparal
Type: enhancement | Status: new
Priority: major | Milestone:
Component: harness | Version: 1.0
Keywords: |
-------------------------+--------------------------------------------------
Currently when we schedule a job and it fails, we just print it out and
forget about it:
{{{
retval = schedule_job(control, email=email, name=testname,
required_arch=arch, dryrun=opts.dryrun,
labels=aq_labels)
if retval != 0:
print "ERROR: failed to schedule job %s" % testname
}}}
That should not be the case. We should:
* use syslog and log important stuff to /var/log/autoqa.log or similar
* send an email about failed scheduling to autoqa-results
That way we will know something is wrong and will be able to fix it.
Otherwise it just silently fails and we don't know about it.
Feel free to reassign the ticket if you want to work on it.
--
Ticket URL: <https://fedorahosted.org/autoqa/ticket/196>
AutoQA <http://autoqa.fedorahosted.org>
Automated QA project
12 years, 5 months