autoqa-devel December 2011

autoqa-devel@lists.fedorahosted.org

8 participants
37 discussions

rats_install test updated for review
by Hongqing Yang 03 Feb '12

03 Feb '12

Greeting, 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 http://git.fedorahosted.org/git/?p=autoqa.git;a=tree;h=refs/heads/rats_inst… 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. Hongqing

2 14

[AutoQA] #289: Missing autotest debug logs
by fedora-badges 12 Jan '12

12 Jan '12

#289: Missing autotest debug logs ----------------------+----------------------------------------------------- Reporter: kparal | Owner: Type: defect | Status: new Priority: major | Milestone: Hot issues Component: autotest | Keywords: ----------------------+----------------------------------------------------- I've found a test run where autotest debug logs are missing. What's wrong? We need them. http://autoqa.fedoraproject.org/results/72107-autotest/qa06.c.fedoraproject… -- Ticket URL: <https://fedorahosted.org/autoqa/ticket/289> AutoQA <http://autoqa.fedorahosted.org> Automated QA project

1 7

autoqa-results@ results archive disabled
by James Laska 21 Dec '11

21 Dec '11

Greetings gang, 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) /etc/cron.d/autoqa 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. Thanks, James

3 6

production server environment
by Hongqing Yang 19 Dec '11

19 Dec '11

Greetings, 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. Hongqing

2 3

[AutoQA] #321: Store test logs for at least a month
by fedora-badges 16 Dec '11

16 Dec '11

#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

1 5

Impact of treebuilder on AutoQA, and RATS?
by Adam Williamson 16 Dec '11

16 Dec '11

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: https://fedoraproject.org/wiki/Anaconda/Features/Lorax-TreeBuilder I filed a ticket for the specific impact on the compose_tree test: https://fedorahosted.org/autoqa/ticket/392 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? -- Adam Williamson Fedora QA Community Monkey IRC: adamw | Twitter: AdamW_Fedora | identi.ca: adamwfedora http://www.happyassassin.net

4 6

stage: hanging jobs
by Kamil Paral 15 Dec '11

15 Dec '11

I noticed today that we have about 50 queued x86_64/noarch depchecks on our staging server. The problem was in this job: http://autoqa-stg.fedoraproject.org/results/2335-autotest/virt27.qa/debug/ 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.

3 15

[AutoQA] #393: depcheck crashes for F16
by fedora-badges 13 Dec '11

13 Dec '11

#393: depcheck crashes for F16 ----------------------+----------------------------------------------------- Reporter: kparal | Owner: Type: defect | Status: new Priority: critical | Milestone: Hot issues Component: tests | Keywords: ----------------------+----------------------------------------------------- This is happening on both production and staging server: {{{ 12/13 08:00:09 DEBUG|base_utils:0106| [stdout] Temp dirs /tmp/depcheck.VaUm9m and /tmp/depcheck-accepted._mwdxL created. 12/13 08:00:09 DEBUG|base_utils:0106| [stdout] Checking packages against repo f16-updates-testing (parents: f16-updates f16) 12/13 08:00:09 DEBUG|base_utils:0106| [stdout] removing temp dirs /tmp/depcheck.VaUm9m and /tmp/depcheck-accepted._mwdxL 12/13 08:00:09 ERROR|base_utils:0106| [stderr] Traceback (most recent call last): 12/13 08:00:09 ERROR|base_utils:0106| [stderr] File "./depcheck", line 88, in <module> 12/13 08:00:09 ERROR|base_utils:0106| [stderr] profile=opts.profile) 12/13 08:00:09 ERROR|base_utils:0106| [stderr] File "/usr/share/autotest/tests/depcheck/depcheck_lib.py", line 394, in depcheck_main 12/13 08:00:09 ERROR|base_utils:0106| [stderr] test_dir=temp_dir, accepted_dir=acc_dir) 12/13 08:00:09 ERROR|base_utils:0106| [stderr] File "/usr/share/autotest/tests/depcheck/depcheck_lib.py", line 312, in do_depcheck 12/13 08:00:09 ERROR|base_utils:0106| [stderr] _rpmdb = yum_repos.pkgSack 12/13 08:00:09 ERROR|base_utils:0106| [stderr] File "/usr/lib/python2.7 /site-packages/yum/__init__.py", line 892, in <lambda> 12/13 08:00:09 ERROR|base_utils:0106| [stderr] pkgSack = property(fget=lambda self: self._getSacks(), 12/13 08:00:09 ERROR|base_utils:0106| [stderr] File "/usr/lib/python2.7 /site-packages/yum/__init__.py", line 673, in _getSacks 12/13 08:00:09 ERROR|base_utils:0106| [stderr] self.repos.populateSack(which=repos) 12/13 08:00:09 ERROR|base_utils:0106| [stderr] File "/usr/lib/python2.7 /site-packages/yum/repos.py", line 294, in populateSack 12/13 08:00:09 ERROR|base_utils:0106| [stderr] sack.populate(repo, mdtype, callback, cacheonly) 12/13 08:00:09 ERROR|base_utils:0106| [stderr] File "/usr/lib/python2.7 /site-packages/yum/yumRepo.py", line 164, in populate 12/13 08:00:09 ERROR|base_utils:0106| [stderr] if self._check_db_version(repo, mydbtype): 12/13 08:00:09 ERROR|base_utils:0106| [stderr] File "/usr/lib/python2.7 /site-packages/yum/yumRepo.py", line 222, in _check_db_version 12/13 08:00:09 ERROR|base_utils:0106| [stderr] return repo._check_db_version(mdtype) 12/13 08:00:09 ERROR|base_utils:0106| [stderr] File "/usr/lib/python2.7 /site-packages/yum/yumRepo.py", line 1264, in _check_db_version 12/13 08:00:09 ERROR|base_utils:0106| [stderr] repoXML = self.repoXML 12/13 08:00:09 ERROR|base_utils:0106| [stderr] File "/usr/lib/python2.7 /site-packages/yum/yumRepo.py", line 1463, in <lambda> 12/13 08:00:09 ERROR|base_utils:0106| [stderr] repoXML = property(fget=lambda self: self._getRepoXML(), 12/13 08:00:09 ERROR|base_utils:0106| [stderr] File "/usr/lib/python2.7 /site-packages/yum/yumRepo.py", line 1459, in _getRepoXML 12/13 08:00:09 ERROR|base_utils:0106| [stderr] raise Errors.RepoError, msg 12/13 08:00:09 ERROR|base_utils:0106| [stderr] yum.Errors.RepoError: Cannot retrieve repository metadata (repomd.xml) for repository: f16. Please verify its path and try again }}} http://autoqa.fedoraproject.org/results/257273-autotest/virt05.qa.fedorapro… -- Ticket URL: <https://fedorahosted.org/autoqa/ticket/393> AutoQA <http://autoqa.fedorahosted.org> Automated QA project

1 2

[PATCH] schedule noarch tests on machines with 'noarch' autotest label
by Kamil Paral 09 Dec '11

09 Dec '11

Please review: https://fedorahosted.org/reviewboard/r/244/

4 9

[PATCH 0/3] Allow creating DEVEL builds
by Kamil Paral 09 Dec '11

09 Dec '11

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 or make srpm DEVEL=1 pr 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(-) -- 1.7.7.3

3 9

2026

2025

2024

2023

2022

2021

2020

2019

2018

2017

2016

2015

2014

2013

2012

2011

2010

2009

autoqa-devel December 2011