Beakerlib based initscript checker
by Josef Skladanka
Hi gang,
I just pushed a new test into the beakerlib branch in git
<http://git.fedorahosted.org/git/?p=autoqa.git;a=shortlog;h=refs/heads/bea...>
which aggregates some initscript tests stolen from our RHEL BaseOS
colleagues :)
Basically, it has a directory structure tests/$PACKAGE_NAME and runs the
test according to the name parameter from post-koji-build hook.
I belive, that it should be simple to add more tests, by simply creating
new directories with appropriate content (thx to kparal for this awesome
idea).
Hope you'll like it :)
Joza
14 years, 1 month
2010-02-12 - AutoQA resultsdb design session
by James Laska
# AutoQA ResultsDB Discussion
# Date: 2010-02-12
# Time: 15:00 UTC (10:00 EST, 16:00 CET)
# Participants - kparal, wwoods, jskladan, jlaska
= Introduction =
Discussed how we would handle the meeting -
http://en.wikipedia.org/wiki/Design_thinking
= Define =
* Decide what issue(s) we're trying to solve
* Kamil described how AutoQA tests run now -- results currently sent
to mailing list
* Should this track general test results (from koji or other), or just
AutoQA test results? -- focus on AutoQA test results
* A common store that different views can draw from
* What test results do we want to see?
* Install test results (against trees/release candidates)
* Package tests - store metadata to the tests [we should define
required metadata]
* Build tests
* Not trying to write different views ... just focus on a common
results aggregator
* Provide storage and display of results for test writers
* More useful, context-specific views of test result data
* Agree on who the audience is
* Focus on developers/testers
* Possibly Fedora community as a view to the data
* Establish a glossary of terms
* State the obvious
* we want to store only "our" data (~ test results & metadata), not
including other tools data - other than that, we should store a link to
brew/koji/... result along with the test results
* Determine what success would look like
* A results db holding results for multiple types of tests
* API for storing and retrieving data
* Different views to the same data - separate frontends (or one
frontend with several views for like installation test/package test)
= Research =
* Review the history of the problem
* israwhidebroken provides a db
* results sent to the mailing list
* Remember existing obstacles
* RHTS/beaker does a *great* job gathering results and relevant log
files, but
* Collect examples of other attempts to solve the problem
* israwhidebroken provides a db and a front-end to the data
* spike source - defined data formats?
* RHTS - dkovalsk/bpeck?
* how does it store data
* which "fields" should be required/optional for tests in general
etc.
* TCMS (nitrate) - how is it storing test results, what information is
recorded
* rpmdiff - dmalcolm?
* TPS (Package sanity) - psplichal
* Research questions for other tools
* What data is required for generic test results?
* What information is included (logs, timestamps?)
* How is benchmark data recorded?
* How is the data used?
* What are the most important data to collect?
* Note project supporters/investors/critics
* QA needs this to aid developing front-ends for test groups (install,
package)
= Tasks =
* [jlaska] - Setup a wiki page to store research
* [kparal] - ask dkovalsky about RHTS, psplicha about TPS
* [wwoods] - nitrate results research
* [jlaska] - rpmdiff results research
= Next meeting =
* 2010-02-19 - E-checkin
* 2010-02-26 - next gobby+ftalk session
14 years, 2 months
/etc/cron.d/autoqa
by Kamil Paral
Currently, the file
/etc/cron.d/autoqa
is installed by the "make install". I think we should leave
it out from Makefile and leave it just as a file in RPM file.
Why?
1. Because it's a config file (it's correctly marked in spec file
as such). We don't want to overwrite config file for every
"make install". That's the reason why neither autoqa.conf nor
repoinfo.conf are install by "make install", not to overwrite them.
2. Because I don't want to run autoqa using cron, but every "make
install" copies the cron file back.
We can either remove it from Makefile completely or we can make a
check and install it only if no such file is currently present
(we can also use this approach for other config files - autoqa.conf,
repoinfo.conf).
Do you think I can make that change?
14 years, 2 months
[PATCH] Updates for No Frozen Rawhide (NFR), which include: * Enabling dist-f13 and dist-f14-updates-candidate in post-koji-build * Update repoinfo.conf with f13 urls * Update parent tag info in koji_utils.py
by James Laska
---
hooks/post-koji-build/watch-koji-builds.py | 2 ++
lib/python/koji_utils.py | 2 ++
repoinfo.conf | 17 ++++++++++++++++-
3 files changed, 20 insertions(+), 1 deletions(-)
diff --git a/hooks/post-koji-build/watch-koji-builds.py b/hooks/post-koji-build/watch-koji-builds.py
index d1b1707..2dcfc6d 100755
--- a/hooks/post-koji-build/watch-koji-builds.py
+++ b/hooks/post-koji-build/watch-koji-builds.py
@@ -35,6 +35,8 @@ kojiserver = 'http://koji.fedoraproject.org/kojihub'
taglist = set(('dist-f10-updates-candidate',
'dist-f11-updates-candidate',
'dist-f12-updates-candidate',
+ 'dist-f13-updates-candidate',
+ 'dist-f14-updates-candidate',
))
archlist = ('i686', 'x86_64', 'noarch')
diff --git a/lib/python/koji_utils.py b/lib/python/koji_utils.py
index e7c3d26..c9fad5d 100644
--- a/lib/python/koji_utils.py
+++ b/lib/python/koji_utils.py
@@ -25,6 +25,8 @@ from repoinfo import repoinfo
import rpmUtils.miscutils
parents_for_tag = {
+ 'dist-f14-updates-candidate': ('f14','f14-updates','f14-updates-testing'),
+ 'dist-f13-updates-candidate': ('f13','f13-updates','f13-updates-testing'),
'dist-f12-updates-candidate': ('f12','f12-updates','f12-updates-testing'),
'dist-f11-updates-candidate': ('f11','f11-updates','f11-updates-testing'),
'dist-f10-updates-candidate': ('f10','f10-updates','f10-updates-testing'),
diff --git a/repoinfo.conf b/repoinfo.conf
index f358dc5..0b66c1c 100644
--- a/repoinfo.conf
+++ b/repoinfo.conf
@@ -3,7 +3,7 @@ parents =
arches = i386, x86_64, ppc
# tag defaults to dist-[section_name]
tag = dist-%(__name__)s
-baseurl = http://gromit.redhat.com/pub/fedora/linux
+baseurl = http://download.fedoraproject.org/pub/fedora/linux
goldurl = %(baseurl)s/releases/%(path)s/Everything/%(arch)s/os
updatesurl = %(baseurl)s/updates/%(path)s/%(arch)s
rawhideurl = %(baseurl)s/%(path)s/%(arch)s/os
@@ -13,6 +13,21 @@ arches = i386, x86_64
path = development
url = %(rawhideurl)s
+[f13]
+# path will change when Fedora 13 is released
+path = development/13
+url = %(rawhideurl)s
+
+[f13-updates]
+path = 13
+url = %(updatesurl)s
+parents = f13
+
+[f13-updates-testing]
+path = testing/13
+url = %(updatesurl)s
+parents = f13-updates, f13
+
[f12]
path = 12
url = %(goldurl)s
--
1.6.6
14 years, 2 months
Several updates to watch_for_step() for improved monitoring
by James Laska
Greetings,
Was trying to debug why rats_install was timing out while monitoring /tmp/anaconda.log for install progress. Turns out the log format changed for /tmp/anaconda.log to cause the string matching to fail. I've updated the matching to use a regular expression and tested it against rawhide, Fedora 12 and Fedora 11 anaconda.log formats.
Also, there appears to be a typo in watch_for_step() where it checks for the presence of a /tmp/anacdump.txt file.
I'll be running the changes through a few additional tests in the morning. Comments appreciated.
Thanks,
James
14 years, 2 months
Status/issues of auto installation
by Li Ming
Greetings,
I am writing the following to tell you what the progress of auto
install and what issues we are facing now. I have developed a script
which can do DVD+ kickstart auto install,you can download and run it:
# git clone git://git.fedorahosted.org/autoqa.git
# cd autoqa/tests/anaconda
# you need to install libguestfs, group install
Virtualization,python-virtinst ,etc... first
# mount -o loop DVDImage.iso /InstallTree
Then you can run it like this:
1. http/ftp... kickstart file:
./dvd_install.py -k http://server/ks.cfg -a i386 -d /InstallTree |tee
test.log
2. local kickstart file:
./dvd_install.py -k /path/to/ks.cfg -a i386 -d /InstallTree |tee test.log
3. remote install tree:
./dvd_install.py -k /path/to/ks.cfg -a i386 -d http://install/tree |tee
test.log
./dvd_install.py -k http://server/ks.cfg -a i386 -d ftp://install/tree
|tee test.log
.....
but we prefer the second one:
2. local kickstart file:
./dvd_install.py -k /path/to/ks.cfg -a i386 -d /InstallTree |tee test.log
because we want to imitate a true local DVD install, but this test still
has an issue: In this test,the virt-install --location still will
activate network which request a DHCP server, this will be a big problem
for testers who are not in DHCP environment. If use virt-install --cdrom
will get what we want: imitate true local DVD install,but the ks
parameter can not be passed to grub in this case. If try to solve these
problems, we have such options:
# uncompress the ISO,then update the syslinux kernel args,then build ISO
again,my concern is this will consume big resource and it will waste
lots of time before each test.
# Guys from virt list give us a solution:
call qemu directly:
qemu -name 'vm1' -monitor
unix:/tmp/monitor-20100207-221920-Q1pS,server,nowait -drive
file=/var/lib/libvirt/images/fedoratest.img -drive
file=/var/lib/libvirt/images/ksdata.img -net nic,vlan=0 -net user,vlan=0
-m 512 -smp 1 -drive
file=/nfs/iso/f12-ga/Fedora-12-i386-DVD.iso,index=2,media=cdrom -fda
/var/lib/libvirt/images/ksdata.img -tftp /var/lib/tftpboot -boot d
-bootp /pxelinux.0 -boot n -redir tcp:5000::22
This method works,the network was not activated,because the pxe install
can help download boot file and start system,this is before the system
can active network.But this method needs to copy the pxelinux.0 to tftp
server root directory,if the tester did not install syslinux, the
install will fail,I am not sure whether this will demand that the host
and the guest VM have the same system. because pxelinux.0 is located in
host system. The vmlinuz and initrd.img also have to be copied from iso
to tftp directory and the default config file need to be created. I have
some concerns about this method:
1. The qemu is very slow, I tested the whole installation,even the
hardware is very good, the install speed is still very slow.
2. The install needs to copy a pxelinux.0 file to tftp server root
directory, the pxelinux.0 was provided by syslinux which has to be
installed on host,that means the host and the guest should install the
same system? if we want to test f13, the host system has to be f13? If
it's true, we have to update the syslinux every time.
3. the virt-install --location can handle the remote installation,
if we want to support remote install in the future, virt-install --cdrom
is not a good choice
# James Laska provided a method: use dogtail to pass args to
virt-viewer.It will append the supplied boot arguments to the guest and
initiate a kickstart DVD install. I still did not get time to try it
till now.
Thanks
Liam
14 years, 2 months
DVD auto install test script
by Li Ming
Hi,
I write a very simple DVD auto install test script by referring
Will Woods's install script.Many thanks for Will.:) This is my first
Python script,it is definitely not good. I will take this script as a
starting-point,hope can write some high-qualified scripts in the future.
This script only supports DVD + kickstart install. If you want to try
it,please modify the attached ks.cfg to specify install source first.
this kickstart file can be accessed by http or ftp. Before run it, you
need to install virtualization,python-virtinst... Run the script like this:
mount -o loop DVDImage.iso /InstallTree
./dvd_install.py -k http://server/ks.cfg -a i386 -d /InstallTree |tee
test.log
I did not put it to git because some account issues. I will upload
later. See the attachments.
Thanks
Liam
14 years, 2 months
