The rats_install test has been updated to adapt the F16 release and to use rsyslog to get logs,
--initrd-inject is used to attach the ks file instead of to compress the ks file into initrd.img manually.
The source codes can be found in branch rats_install
irb is not configured currently.
some functions there are not used by rats_install, I just leave them there for future ISO installation. They will
not affect other parts of the autoqa, just leave them there.please kindly review it and give me your feedback. Thanks.
Just a heads up ...
It looks like autoqa-results@ hasn't been doing its exercises. It has become
so saturated with autoqa test result emails (~ 8-13k/day), that it's slowing
down mailman on fedorahosted.org, and causing delivery issues for other lists.
After discussing with the Fedora infrastructure team, it was determined
immediate action was needed to allow other lists on fedorahosted.org to
continue receiving mail. We performed the following ...
1) Disabled autoqa-results@ delivery on autoqa.fedoraproject.org immediately
I commented out result_email in /etc/autoqa/autoqa.conf
2) Increase the autoqa.fp.org results time from 30days to 60days (we have disk
space to allow this)
0 3 * * * autotest /usr/sbin/tmpwatch -vv --dirmtime -umc -f 1440 /usr/share/autotest/results/ -X README
This should address the problem in the short term, but adjustments may be
needed on to recognize that autoqa-results@ archive no longer available. It
seems that the volume+size of autoqa-results@ mails increased dramatically
recently. I'm not clear why, so that might be interesting to diagnose. This
also helps us determine whether autoqa-results@ is still the best option for
long-term test result storage, or if there are other options worth pursuing.
May I get some information about our production server, what system is it, RHEL or Fedora?
Which account is used to run all the tests, 'root', 'autotest' or sth else?
what about the partition space, we should decide where should we put all the ISOs downloaded and
the ISO build by compose_tree. Thanks.
#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
(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>
Automated QA project
Hey, folks. I was thinking this week that, in the context of the RATS
discussion, it's probably worth looking at the big changes to lorax
coming out of the treebuilder branch:
I filed a ticket for the specific impact on the compose_tree test:
But I wondered if the change has any other impacts on AutoQA in general,
and RATS. Does it make it more or less viable that we could simply
automate the creation of boot.iso for RATS runs, and avoid asking releng
to provide it for us? Or is this still something releng should own and
we should co-ordinate with releng on?
Fedora QA Community Monkey
IRC: adamw | Twitter: AdamW_Fedora | identi.ca: adamwfedora
I noticed today that we have about 50 queued x86_64/noarch depchecks on our staging server. The problem was in this job:
It was hanging for two days in the "running" state. This seems like an autotest problem, it should detect when connection times out and it should abort the job automatically. (But now I'm not sure if we didn't make some adjustments the autotest's watchdog timer, we need to investigate).
I aborted the hanging job and all but the last two depchecks.
If this happens again we should investigate and report to autotest devs.
This is a series of 3 patches. Please view them at origin/stage_build or here.I did not use RB because it can't do patch series and the changes would be confusing if combined into a single patch.
We already stumbled onto a problem that we need to update spec file every time we want to update staging environment. That's really bad, ideally we want to update after every major commit (like my yesterday's patch). I have modified Makefile (I officially announce that I hate the syntax) to allow us to create development autoqa builds without modifying spec file. You just execute:
make archive DEVEL=1
make srpm DEVEL=1
make mock DEVEL=1
and here we go. The rpm file then looks like this 'autoqa-0.7.1_devel_v0.5.0_1_63_g5a41715-1.fc16.noarch.rpm'. Pretty long, but its an ascending sequence, which suffices. This can be built directly on stage server and then installed. No need to change the spec file, no need to commit it to git. Voila.
Kamil Páral (3):
autoqa.spec: replace $(NAME) with 'autoqa'
Makefile: allow creating DEVEL builds
autoqa.spec: remove pre-release statements in changelog
Makefile | 172 ++++++++++++++++++++++++++++++++---------------------------
autoqa.spec | 18 ------
2 files changed, 93 insertions(+), 97 deletions(-)