December 2011 - autoqa-devel - Fedora mailing-lists

[AutoQA] #251: Move autotest applications into /usr/*bin
by fedora-badges 26 Sep '12

26 Sep '12

#251: Move autotest applications into /usr/*bin -----------------------+---------------------------------------------------- Reporter: jlaska | Owner: Type: task | Status: new Priority: minor | Milestone: Packaging, Review, & Deployment Component: packaging | Keywords: -----------------------+---------------------------------------------------- The autotest package should supply binaries in /usr/bin/ ... so we can rely on PATH and not have to call autotest with the full-path (/usr/share/autotest/client/bin/autotest) when scheduling jobs in '/usr/bin/autoqa'. Alternatively, the autotest package could drop a script that updates PATH appropriately into /etc/profile.d/autotest. But yuck. -- Ticket URL: <https://fedorahosted.org/autoqa/ticket/251> AutoQA <http://autoqa.fedorahosted.org> Automated QA project

1 2

[AutoQA] #191: Submit autotest for Fedora package approval
by fedora-badges 26 Sep '12

26 Sep '12

#191: Submit autotest for Fedora package approval -----------------------+---------------------------------------------------- Reporter: jlaska | Owner: Type: task | Status: new Priority: major | Milestone: Packaging and Review Component: packaging | Version: 1.0 Keywords: | -----------------------+---------------------------------------------------- * https://bugzilla.redhat.com/show_bug.cgi?id=548522 Currently stalled, pending packaging of the gwt package. This includes packaging all bundled .jar files included with gwt. -- Ticket URL: <https://fedorahosted.org/autoqa/ticket/191> AutoQA <http://autoqa.fedorahosted.org> Automated QA project

1 3

[AutoQA] #157: conflicts: requested arch not respected
by fedora-badges 06 Aug '12

06 Aug '12

#157: conflicts: requested arch not respected --------------------+------------------------------------------------------- Reporter: kparal | Owner: Type: defect | Status: new Priority: major | Milestone: Component: tests | Version: 1.0 Keywords: | --------------------+------------------------------------------------------- This is a bug in the potential_conflict.py script in tests/conflicts/. Usage suggests using --arch options for specifying requested architecture to be tested. But if you look at the attached log, the first and second output match (that's correct), but the third doesn't match, even though it should. Everything was tested on x86_64 machine. Also from the usage line it is not clear whether --arch is related only to particular yum repository selection (replacing $basearch keyword), or whether it also relates to packages built for one architecture but being in different repo (e.g. i686 packages are very often in x86_64 repo). I have looked into the source code of the script and it seems that the --arch option is not used at all, just printed out in the usage help?? Seth, you're listed as script author. Any comments on that? Thanks. -- Ticket URL: <https://fedorahosted.org/autoqa/ticket/157> AutoQA <http://autoqa.fedorahosted.org> Automated QA project

1 7

[AutoQA] #270: Package and submit for review - compat-Django-1.0.4
by fedora-badges 02 Aug '12

02 Aug '12

#270: Package and submit for review - compat-Django-1.0.4 -----------------------+---------------------------------------------------- Reporter: jlaska | Owner: Type: task | Status: new Priority: major | Milestone: Package Update Acceptance Test Plan Component: packaging | Keywords: -----------------------+---------------------------------------------------- Currently packaged so that it can coexist with the current Django package (see http://repos.fedorapeople.org/repos/fedora- qa/autoqa/fedora-14-testing/). I need to port existing security patches linked from http://www.djangoproject.com/weblog/2010/dec/22/security/ Once patched, submit for review ... and enjoy. Eventually autotest will be updated to use Django-1.2 ... but packaging Django-1.0.4 removes one more packaging obstacle to having autotest as an official Fedora package. -- Ticket URL: <https://fedorahosted.org/autoqa/ticket/270> AutoQA <http://autoqa.fedorahosted.org> Automated QA project

1 2

[AutoQA] #329: implement RPM checksum verification
by fedora-badges 30 Jul '12

30 Jul '12

#329: implement RPM checksum verification -------------------------+-------------------------------------------------- Reporter: kparal | Owner: Type: enhancement | Status: new Priority: major | Milestone: Finger Food Component: core | Keywords: -------------------------+-------------------------------------------------- Currently this method is in autoqa.util module: {{{ 261 def valid_rpm(rpm_file): 262 '''Check that RPM file is valid. 263 Note: This currently only extracts RPM header and presumes the file is 264 OK if that succeeds. Full RPM hashsum check would be nice to have 265 implemented too (FIXME). 266 @param rpm_file RPM file path 267 @return True if file seems OK or False if there is some problem (file 268 can't be read, RPM header is corrupt) 269 ''' ... }}} We would like to have full RPM checksum verification, not just reading the header and saying that it's OK. Find out how to do it and change the method accordingly. It would be nice to have a method argument to enable full checksum verification/fall back to original header verification, because it can be performance intensive operation and it may not be suitable for all our use cases). -- Ticket URL: <https://fedorahosted.org/autoqa/ticket/329> AutoQA <http://autoqa.fedorahosted.org> Automated QA project

1 3

[AutoQA] #206: Update bodhi to enforce Package Update Acceptance policy
by fedora-badges 26 Mar '12

26 Mar '12

#206: Update bodhi to enforce Package Update Acceptance policy ----------------------------+----------------------------------------------- Reporter: wwoods | Owner: Type: task | Status: new Priority: major | Milestone: Package Update Acceptance Test Plan Component: infrastructure | Version: 1.0 Keywords: | ----------------------------+----------------------------------------------- In order to enforce the Package Update Acceptance Test Plan, Bodhi will need be modified to reject the push of any package that fails acceptance testing. The acceptance tests may need to send status/data to bodhi in order for it to make decisions about policy (see e.g. ticket #205). Later bodhi might just get data from resultdb (see that milestone for details). -- Ticket URL: <https://fedorahosted.org/autoqa/ticket/206> AutoQA <http://autoqa.fedorahosted.org> Automated QA project

1 7

[AutoQA] #252: Provide all autotest client combinations that we need
by fedora-badges 16 Mar '12

16 Mar '12

#252: Provide all autotest client combinations that we need ------------------------+--------------------------------------------------- Reporter: kparal | Owner: Type: task | Status: new Priority: major | Milestone: 0.5.0 Component: production | Keywords: ------------------------+--------------------------------------------------- Currently our production server at http://autoqa.fedoraproject.org/ has 6 autotest clients assigned, all bare metals with Fedora 13 installed, with mixed architectures. But we need more. According to https://fedoraproject.org/wiki/Managing_autotest_labels we have two architecture labels, two fedora release labels (the two currently supported Fedora releases, I would omit Rawhide for now) and two virt labels (virtual machine or bare metal). We need machines for every combination of those labels (that is 8 IICC - if I count correctly). And we would like to see a bit more 64bit machines, because we use them for noarch tests. Currently the only test that really requires all those combinations is initscripts test. But there will be more in the future. It is quite some farm, but it seems we'll have to build it. -- Ticket URL: <https://fedorahosted.org/autoqa/ticket/252> AutoQA <http://autoqa.fedorahosted.org> Automated QA project

1 3

[AutoQA] #391: re-enable autoqa-results ML
by fedora-badges 16 Mar '12

16 Mar '12

#391: re-enable autoqa-results ML ------------------------+--------------------------------------------------- Reporter: kparal | Owner: Type: task | Status: new Priority: major | Milestone: 0.8.0 Component: production | Keywords: ------------------------+--------------------------------------------------- Read these threads: * https://fedorahosted.org/pipermail/autoqa- devel/2011-September/002894.html * https://fedorahosted.org/pipermail/autoqa- devel/2011-October/002898.html Find and implement fix so that we can easily inspect the test results again. -- Ticket URL: <https://fedorahosted.org/autoqa/ticket/391> AutoQA <http://autoqa.fedorahosted.org> Automated QA project

1 9

[AutoQA] #373: ResultsDB: Add 'store to ResultsDB' functionality to test.py
by fedora-badges 14 Mar '12

14 Mar '12

#373: ResultsDB: Add 'store to ResultsDB' functionality to test.py ----------------------+----------------------------------------------------- Reporter: jskladan | Owner: jskladan Type: task | Status: new Priority: major | Milestone: 0.7.0 Component: resultdb | Keywords: ----------------------+----------------------------------------------------- In order to store data into resultsdb, we need to create a method which will access resultsdb's XMLRPC interface and store data from inside the post_results() method. -- Ticket URL: <https://fedorahosted.org/autoqa/ticket/373> AutoQA <http://autoqa.fedorahosted.org> Automated QA project

1 4

[AutoQA] #255: Use Config class to simplify access to configuration options
by fedora-badges 07 Mar '12

07 Mar '12

#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

1 6

[AutoQA] #350: Add support for using file proxy
by fedora-badges 07 Mar '12

07 Mar '12

#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

1 9

[AutoQA] #390: update rats_install
by fedora-badges 07 Mar '12

07 Mar '12

#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

1 25

[AutoQA] #338: AutoQATest.version - is it needed?
by fedora-badges 06 Mar '12

06 Mar '12

#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

1 5

[AutoQA] #186: Automate media kit sanity tests
by fedora-badges 05 Mar '12

05 Mar '12

#186: Automate media kit sanity tests --------------------+------------------------------------------------------- Reporter: jlaska | Owner: lili Type: task | Status: new Priority: major | Milestone: Automate installation test plan Component: tests | Version: 1.0 Keywords: | --------------------+------------------------------------------------------- This ticket is intended to track automating the mediakit sanity tests (http://fedoraproject.org/wiki/Category:Installer_Image_Sanity_Test_Cases) Discussion already underway, along with code in Liam's private branch. For details see https://fedorahosted.org/pipermail/autoqa- devel/2010-June/000595.html -- Ticket URL: <https://fedorahosted.org/autoqa/ticket/186> AutoQA <http://autoqa.fedorahosted.org> Automated QA project

1 9

[AutoQA] #392: Check whether compose_tree needs updating for F17 compose changes (treebuilder)
by fedora-badges 05 Mar '12

05 Mar '12

#392: Check whether compose_tree needs updating for F17 compose changes (treebuilder) ----------------------+----------------------------------------------------- Reporter: adamwill | Owner: tflink Type: task | Status: new Priority: major | Milestone: 0.8.0 Component: tests | Keywords: ----------------------+----------------------------------------------------- I don't really grok the details, but I know there have been some changes to the image compose process post-F16, involving a new branch of lorax called treebuilder: https://fedoraproject.org/wiki/Anaconda/Features/Lorax-TreeBuilder wwoods has a guide up at: https://fedoraproject.org/wiki/User:Wwoods/Building_images_with_treebuilder We should check the impact of this change on AutoQA. immediately, does the compose_tree script need updating? -- Ticket URL: <https://fedorahosted.org/autoqa/ticket/392> AutoQA <http://autoqa.fedorahosted.org> Automated QA project

1 3

[AutoQA] #194: Incorporate automated anaconda storage suite
by fedora-badges 05 Mar '12

05 Mar '12

#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

1 1

[AutoQA] #361: improve pretty log output for anaconda tests
by fedora-badges 05 Mar '12

05 Mar '12

#361: improve pretty log output for anaconda tests --------------------+------------------------------------------------------- Reporter: jlaska | Owner: Type: task | Status: new Priority: minor | Milestone: Finger Food Component: tests | Keywords: --------------------+------------------------------------------------------- With the advent of the super awesome html pretty logs, some of the less frequented tests are in need of some care and feeding. While reviewing installer test results with the anaconda team, I noticed that the installer tests don't all look good with pretty logs. Sample output for existing anaconda test results ... * [http://autoqa.fedoraproject.org/results/143510-autotest/qa02.qa.fedoraproje… anaconda_storage] - Doesn't look bad ... I don't think I'd recommend changes here. * [http://autoqa.fedoraproject.org/results/143512-autotest/qa07.qa.fedoraproje… compose_tree] - Missing some info * [http://autoqa.fedoraproject.org/results/143577-apache/10.5.124.249/anaconda… anaconda_checkbot] - Yuck, no info at all :( This ticket is intended to address improving the html result output for the above installer tests. -- Ticket URL: <https://fedorahosted.org/autoqa/ticket/361> AutoQA <http://autoqa.fedorahosted.org> Automated QA project

1 11

[AutoQA] #363: depcheck: don't require specific release
by fedora-badges 15 Feb '12

15 Feb '12

#363: depcheck: don't require specific release -------------------------+-------------------------------------------------- Reporter: kparal | Owner: Type: enhancement | Status: new Priority: minor | Milestone: Finger Food Component: tests | Keywords: -------------------------+-------------------------------------------------- Depcheck currently requires machine with a specific Fedora release installed to test matching repositories. From tests/depcheck/control.autoqa: {{{ # because we simulate installing packages, the autotest label of the correct distribution # must be present (like 'fc13') If proper label is not found the test will not execute if autoqa_args.has_key('nvrs'): from autoqa.util import get_distro distro = get_distro(autoqa_args['nvrs'][0]) labels.append(distro) }}} Josef says it's possible to cancel this constraint. That would allow us to test arbitrary repository on arbitrary machine (improving performance and maybe allowing us to have less machines). There is one thing worth mentioning: Depcheck is tightly tied to yum, and any weird behavior might be caused by yum. If we cancel above-mentioned constraint, we can no longer suppose that "depcheck crashed on f15-updates, therefore I should try to reproduce it on my F15 machine". It will be necessary to look which machine the test was executed on and try to reproduce it in the same environment if possible. The goal of this ticket is test properly whether cancelling the requirement works correctly. That means to test executing depcheck for F15 repos on F14 machine, or vice versa, and comparing the results with behavior prior to this change. -- Ticket URL: <https://fedorahosted.org/autoqa/ticket/363> AutoQA <http://autoqa.fedorahosted.org> Automated QA project

1 3

[AutoQA] #335: autotest_server autodetection fails
by fedora-badges 10 Feb '12

10 Feb '12

#335: autotest_server autodetection fails --------------------+------------------------------------------------------- Reporter: kparal | Owner: Type: defect | Status: new Priority: minor | Milestone: Finger Food Component: core | Keywords: --------------------+------------------------------------------------------- Currently if we want to have working hyperlinks to logs, we have to fill in 'autotest_server' in autoqa.conf, because autodetection from hostname get's overwritten by empty value from the log. The links then look like this: http:///results/20-root/brutus.test.redhat.com/helloworld/results/full.log /autoqa: {{{ # Hardcoded defaults for the 'general' section conf = { 'local': 'false', 'testdir': '/usr/share/autotest/client/site_tests', 'eventdir': '/usr/share/autoqa/events', 'notification_email': '', 'autotest_server': socket.gethostname(), } conf = autoqa_conf.get_section('general', conf) conf = autoqa_conf.get_section('notifications', conf) # FIXME: conf['autotest_server'] gets overwritten here by empty value coming # from autoqa_conf }}} We can solve this by some easy hack or more properly by solving ticket #255. -- Ticket URL: <https://fedorahosted.org/autoqa/ticket/335> AutoQA <http://autoqa.fedorahosted.org> Automated QA project

1 1

[AutoQA] #311: Improve Koji call performance with koji.ClientSession.multiCall
by fedora-badges 03 Feb '12

03 Feb '12

#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

1 4

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

[AutoQA] #355: Determine Use Cases for Functional Self Tests
by fedora-badges 07 Dec '11

07 Dec '11

#355: Determine Use Cases for Functional Self Tests ---------------------------+------------------------------------------------ Reporter: tflink | Owner: Type: task | Status: new Priority: minor | Milestone: 0.6.0 Component: documentation | Keywords: ---------------------------+------------------------------------------------ == Description == In order to [ticket:352 create functional test cases] and [ticket:353 create mockups for fedora services], we need to have some idea of the use cases that we would want to test for. Once this information is gathered, we can start creating the tools that we need for better self testing in AutoQA. == Questions to answer == NOTE: please add to this list if anything is missing. * What are we looking to test * Tests (depcheck, upgradepath etc.) * Situations (broken deps, not breaking upgrade path etc.) * What do we need in order to test it * RPM details * Repo contents * Expected Results -- Ticket URL: <https://fedorahosted.org/autoqa/ticket/355> AutoQA <http://autoqa.fedorahosted.org> Automated QA project

1 4

[AutoQA] #345: Implement file locks for all watchers
by fedora-badges 06 Dec '11

06 Dec '11

#345: Implement file locks for all watchers -------------------------+-------------------------------------------------- Reporter: kparal | Owner: Type: enhancement | Status: new Priority: minor | Milestone: Finger Food Component: watchers | Keywords: -------------------------+-------------------------------------------------- In ticket #342 we implemented file lock for koji-bodhi watcher so that it is not run concurrently in multiple instances. Implement the same for all the remaining watchers. -- Ticket URL: <https://fedorahosted.org/autoqa/ticket/345> AutoQA <http://autoqa.fedorahosted.org> Automated QA project

1 5

AutoQA 0.8.0 Planning
by Tim Flink 05 Dec '11

05 Dec '11

Now that 0.7.0 has pretty much been released, it's time to start thinking about 0.8.0. Kamil and I talked about this earlier today and would like to get started on that sooner than later. We'd like to do a phone conference again and the currently proposed time is Thursday, December 1 at 13:30 UTC (05:30 PST, 08:30 EST, 14:30 CET). It's a little early for those of us who are in the US but it seems like a fair compromise with the folks who are in or near Brno time. If you're interested and that time doesn't work for you, let us know and we'll try to come up with a time that works for everyone. It would pretty much need to be this week, though. Tim

5 14

Anaconda UI rewrite + AutoQA
by Kamil Paral 03 Dec '11

03 Dec '11

On our last QA meeting Adam Williamson notified us that there would be an Anaconda hackfest at the next FUDCon and we should raise our concerns (if we had some) regarding AutoQA and the UI re-write. Well, I don't know much about anaconda testing inside AutoQA, I just know we execute some anaconda tests, that's all. But I decided to kick off the discussion and CC relevant people. >From what I know, we have two kind of anaconda tests inside AutoQA: 1. older rats_install test written by Will Woods and executed James Laska in the past 2. newer anaconda_storage, anaconda_checkbot and compose_tree written by Chris Lumens and James Laska I am not sure which of those tests provide important feedback to the anaconda team and whether they are being used at all. Can relevant people provide more details about it? Anaconda team, do you have some specific questions about AutoQA integration and the UI re-write? Will you want to change your tests inside AutoQA in response the new UI and need to have some information from us? I'll happy to answer them if I can. Also, if the test authors have some comments or recommendation about the new UI architecture in order to allow simple automated testing, please post them here. Thanks, Kamil

3 7

AutoQA 0.7 released
by Kamil Paral 01 Dec '11

01 Dec '11

https://kparal.wordpress.com/2011/11/29/autoqa-0-7-released/

1 0

[AutoQA] #368: reconstructe Fedora install test automation framework
by fedora-badges 01 Dec '11

01 Dec '11

#368: reconstructe Fedora install test automation framework ----------------------+----------------------------------------------------- Reporter: hongqing | Owner: hongqing Type: task | Status: new Priority: major | Milestone: Automate installation test plan Component: autotest | Keywords: ----------------------+----------------------------------------------------- A new framework should be constructed to mapping the test cases and kickstart files, and it also should be easy for the users to contribute. A big idea is that one text file will be used to map the test case names and kickstart files, and the kickstart files will be keeped in a directory, during test, the test will iterate all the kickstart in the directory. Users can create new kickstart files in the directory and write the relationship between test case and kickstart in the text file, of course, they can also pass it by arguments instead of doing this. -- Ticket URL: <https://fedorahosted.org/autoqa/ticket/368> AutoQA <http://autoqa.fedorahosted.org> Automated QA project

1 4

Re: #4920: name rules at dl.fp.o/alt/stage
by Hongqing Yang 01 Dec '11

01 Dec '11

The directories will always be named as below: 16-Alpha.TC1 16-Beta.RC1 16.RC1 The difference is for Live. There are only Desktop, KDE, LXDE and XFCE for Alpha and Beta. Live will be separated and other spins will be added for Final, since Alpha and Beta are removed from dl.fp.o/alt/stage, we cannot compare them now. and robatino is doing the deltaisos, if necessary we can contact with him directly. I think currently we just need all the ISOs in directory 16.RC5/Fedora/ Hongqing ----- Original Message ----- > From: "Fedora Release Engineering" <rel-eng(a)fedoraproject.org> > Sent: Thursday, December 1, 2011 11:05:57 AM > Subject: Re: #4920: name rules at dl.fp.o/alt/stage > > #4920: name rules at dl.fp.o/alt/stage > ------------------------------+--------------------------------------------- > Reporter: hongqing | Owner: > rel-eng(a)lists.fedoraproject.org > Type: task | Status: closed > Milestone: Fedora 16 Final | Component: other > Resolution: fixed | Keywords: > ------------------------------+--------------------------------------------- > Changes (by ausil): > > * status: new => closed > * resolution: => fixed > > Comment: > > after talking on IRC things are ok as is > > -- > Ticket URL: <https://fedorahosted.org/rel-eng/ticket/4920#comment:7> > Fedora Release Engineering <http://fedorahosted.org/rel-eng> > Release Engineering for the Fedora Project

1 0

2026

2025

2024

2023

2022

2021

2020

2019

2018

2017

2016

2015

2014

2013

2012

2011

2010

2009

autoqa-devel December 2011