Monthly Archives: January 2009

pykickstart unit tests … follow-up

Just a quick follow-up and thanks to all who participated in the pykickstart unit test event. The list of participants leading up to and during the event includes clumens, alindebe, fcami, adamwill, pfrields, leitz and more (please correct if I’ve left anyone out).

Chris Lumens has incorporated much of the work already into a new pykickstart package. The pykickstart built-in test suite is maturing …

# git://git.fedorahosted.org/pykickstart.git ; cd pykickstart
# make test
*** Running unittests ***
PYTHONPATH=. python tests/baseclass.py -v
runTest (version.StringToVersion_TestCase) ... ok
runTest (version.versionFromFile_TestCase) ... ok
runTest (version.returnClassForVersion_TestCase) ... ok
runTest (version.VersionToString_TestCase) ... ok
runTest (timezone.FC3_TestCase) ... ok
runTest (timezone.FC6_TestCase) ... ok
runTest (monitor.F10_TestCase) ... ok
runTest (monitor.FC6_TestCase) ... ok
runTest (monitor.FC3_TestCase) ... ok
runTest (device.F8_TestCase) ... ok
runTest (device.FC3_TestCase) ... ok
runTest (mediacheck.FC4_TestCase) ... ok
runTest (autopart.FC3_TestCase) ... ok
runTest (autopart.F9_TestCase) ... ok
runTest (interactive.FC3_TestCase) ... ok
runTest (updates.F7_TestCase) ... ok
runTest (keyboard.FC3_TestCase) ... ok
runTest (autostep.FC3_TestCase) ... ok
runTest (clearpart.FC3_TestCase) ... ok
runTest (vnc.FC6_TestCase) ... ok
runTest (vnc.F9_TestCase) ... ok
runTest (vnc.FC3_TestCase) ... ok
runTest (firstboot.FC3_TestCase) ... ok
runTest (logvol.RHEL5_TestCase) ... ok
runTest (logvol.F9_TestCase) ... ok
runTest (logvol.FC3_TestCase) ... ok
runTest (logvol.FC4_TestCase) ... ok
runTest (rootpw.F8_TestCase) ... ok
runTest (rootpw.FC3_TestCase) ... ok
runTest (skipx.FC3_TestCase) ... ok
runTest (selinux.FC3_TestCase) ... ok
runTest (authconfig.FC3_TestCase) ... ok
runTest (lang.FC3_TestCase) ... ok

----------------------------------------------------------------------
Ran 33 tests in 8.315s

OK

Want to get involved…

There are still quite a few more kickstart commands needing tests. If you would like to get involved, I’ve outlined a few steps to contributors …

  1. Checkout the pykickstart development tree:
    # git://git.fedorahosted.org/pykickstart.git ; cd pykickstart
  2. Choose an unimplemented kickstart command from the table below. I’ve organized the commands by difficulty. The more difficult commands are the ones that have changed frequently over time and accept different arguments between versions.
    Less complex deviceprobe.py, displaymode.py, dmraid.py, driverdisk.py, iscsiname.py, key.py, lilocheck.py, logging.py, multipath.py, rescue.py, services.py, volgroup.py, zfcp.py
    Moderate ignoredisk.py, iscsi.py, langsupport.py, method.py, mouse.py, reboot.py, upgrade.py, user.py, zerombr.py,
    More Involved bootloader.py, firewall.py, repo.py, partition.py, xconfig.py, raid.py, network.py

    Already created?

    Over the next few days/weeks, we’ll be adding test cases. Before you start writing a new test, please check the pykickstart git repo to see if the test exists.
  3. Once you select a test to write, reference an existing test for an idea how to get started. For example … checkout the autostep test.
  4. Run your tests by typing:
    # make test TESTSUITE=tests/commands/yourtest.py
  5. Once happy with the results … package up your changes and send them for review:
    # git add tests/commands/yourtest.py     # Add your test locally
    # git commit tests/commands/yourtest.py  # Commit your changes locally
    # git-format-patch origin                # Generate a patch
    # git-send-email --no-chain-reply-to \   # Email the patch
    --in-reply-to 1232731389.3647.308.camel@localhost.localdomain \
    --quiet --to kickstart-list@redhat.com *.patch

Happy testing!

Fedora Test Day – Text-mode install simplification

That’s right … another round of Test Days has begun!  We’ve got a few testing events lined up in the coming weeks, but still looking for volunteers to help host or suggest a future Test Day.

If you are developing a Fedora 11 feature, and would like to get additional scrutiny+testing … don’t hesitate to let me know. The F11 Test day schedule is available on the wiki.

For those not monitoring fedora-test-list, I invite you to come help review and test the proposed text-mode installation simplification changes for Fedora 11.  What you are accustomed to for text-mode installations will be changing in Fedora 11 … come help define how it should behave and help test the proposed changes.  Don’t forget to bring your favorite text-mode use case!

See you this Thursday, January 29 in #fedora-qa.

Got pykickstart?

Chris Lumens and I will be hosting a pykickstart unit test session this Wednesday, January 28, 2009 in #kickstart on irc.freenode.net from 17:00-21:00 UTC (noon – 5pm EST).

What is pykickstart?
Pykickstart is the kickstart processing library used by the anaconda installer, system-config-kickstart, livecd-tools and snake. Pykickstart is able to parse and generate kickstart files for all products from Red Hat Enterprise Linux 3 to Rawhide.
Why test pykickstart?
First, changes to pykickstart can potentially disrupt many other software components. Additionally, automated testing of the anaconda installer has a lot of moving parts. A fully automated system needs a scheduling mechanism, a breadth of hardware to install on, a reporting mechanism (live progress and results), hardware to support remote console+kvm, and hardware to support power cycling failed/timeout tests … oh and more hardware :).

While some of the software support to enable some of the above is coming online with the beaker and nitrate projects. A short-term win is to test the individual pieces that are used to build an installable product (yum, rpm, pyparted, pykickstart, NetworkManager).

Why unit tests?
Unit testing is one of the fastest ways to provide test feedback to a developer. Typically, unit tests do not require additional infrastructure (test case management, test harness, test results storage etc…). As soon as the developer fixes a bug or adds a new feature, [s]he can get immediate test feedback. The don’t have to commit their changes, submit a build, wait until their changes are pulled into rawhide.

The barrier to entry is very low with pykickstart. If you’ve ever seen or written a kickstart file before … you should be familiar with the tests.

How can I help?
Come join IRC channel #kickstart during the event.
  • Share your favorite kickstart scenario’s
  • Help identify test areas
  • Familiarize yourself with python
  • Contribute unit tests
  • Get your name up in lights (okay, the git logs but that’s close).

See you there!

Fedora 11 Test Days – DRAFT schedule

I posted a DRAFT schedule of upcoming Test Day slots to the fedoraproject.org wiki. The schedule now includes major release milestones which makes it easier to see where each slot falls in the schedule. Unfortunately, it has the downside of making the schedule larger and possibly less readable?

I’ll be reaching out to development leads and FESCO members in the coming days to get a better feel for what F11 features they’d like Test Day coverage on. The list of Test Day candidates starts with the Fedora 11 feature list.

Fedora QA needs your help …

Developing a feature for Fedora 11?
Please make sure your efforts get the publicity they deserve by creating a feature page. The process is succinctly outlined at Features/Policy. Currently planned features are available for review.
Does a Fedora 10 feature need extra loving?
Perhaps there is additional polish needed on a Fedora 10 feature? Test Days prior to the Alpha are great for revisiting previously released features to iron out any usability or integration kinks.
Have a new test tool or process that you’d like to discuss?
Test Days are a great forum for discussion and demonstration of software in support of quality control. In addition, there is a world of quality assurance process and procedure out there. Come share your QA expertise.

Please drop me a line if you’d like to request a Test Day topic.

Creating a virtual test lab – part#3

If you’ve been following along, you now have a system installed and configured for creating virtual guests using cobbler. Additionally, cobbler-1.4.0 has been released. I recommend upgrading as there are numerous bug fixes and enhancements that will make life easier (and are required in my setup).

With this setup, you can do just about anything you like with your virtual guests.

  • Need a couple of dedicated systems to test some bodhi updates?
  • Check out the state of rawhide?
  • Want a disposable system to use for an upcoming Fedora Test Day?
  • Or testing out a new Fedora Live image?

I use the my cobbler setup to aid testing the installer, both manual and semi-automated. Let’s start with …

Manual Installs


In this scenario, I’ll configure my guests to boot the installer, but wait for me to manually walk through different use cases. For my installs, I’m going to use Fedora 10 x86_64 which I previously imported using cobbler. Also, I’ll reference the virtual system names created in a previous post (e.g. vguest1, vguest2, etc…).

  1. First, create a kickstart file which we will use only to provide a location for the installation source. The $tree variable will be filled in later by cobbler.
    # echo "url --url \$tree" > /var/lib/cobbler/kickstarts/manual.ks
    
  2. Next, let’s start fresh and remove any virtual guests that are running.
    # virsh destroy vguest1
    # virsh undefine vguest1
  3. Now, tell cobbler what we want to do …
    # cobbler system edit --name vguest1 \
    --profile F-10-GOLD-x86_64 \
    --kickstart /var/lib/cobbler/kickstarts/manual.ks

    Changing boot command-line arguments

    If you wish to pass any arguments to the installer, now is the time to make those changes. The –kopts option can be used to pass any kernel or installer tunables. For example, adding
    --kopts "serial console=ttyS0"

    would enable a text-mode install using ttyS0 on your guest. More information on acceptable boot options for the installer can be found at Anaconda/Options.

  4. Finally, using koan, start the install.
    # koan --server `hostname` --system vguest1 --virt
  5. If all goes well, you should be able to connect to the console of your guest.
    # virt-viewer vguest1

Using the above procedure, you can quickly initiate as many virtual installs as your system (cpu, memory and disk) can handle. Five installs at one time is about the maximum my brain can handle while remembering what I’m trying to accomplish on each system. I repeat the above steps so frequently, I include them in a small shell script for convenience.

Using my script, the above steps can be simplified with just:

# ./install-virt-guest.sh -n vguest1 -p F-10-GOLD-x86_64 -k manual.ks 

Semi-Automated Installs


A bulk of installation testing lies in understanding and using kickstart. The quickest way to get started with kickstart, is to start with a known good kickstart file. From there you can adjust the kickstart to meet your needs.

For me, a great place to look for something to automate is in the Fedora 10 installion test plan. Looking at the test plan, I see that installation using ext4 file systems is not listed. Probably something we’ll want to test in the future. Let’s get started …

  1. On your cobbler server, copy the sample.ks kickstart template to a new filename.
    # cp /var/lib/cobbler/kickstarts/sample.ks /var/lib/cobbler/kickstarts/ext4.ks
  2. Now edit the new file and replace the following line:
    autopart

    With something similar to the following lines:

    part /boot --fstype ext3 --size=200
    part swap --fstype swap --size=512 --grow --maxsize=2016 --recommended
    part / --fstype ext4 --size=1024 --grow
  3. That’s it! Let’s kick off an install on another install using our new cobbler kickstart template.
    # ./install-virt-guest.sh -n vguest2 -p F-10-GOLD-x86_64 -k ext4.ks -c "ext4" 

    Mind the command-line

    Enabling ext4 file system partitioning in Fedora 10 requires booting with an additional kernel command-line. Be sure to add ext4 to your boot parameters.

I’ll leave modelling additional installs using cobbler kickstart templates for the reader. But hopefully this demonstrates how you can easily and quickly perform routine installs using cobbler kickstart templates. You may also wish to further modify your cobbler kickstart templates to meet your needs.

In my next post, I’ll outline how I use SNAKE kickstart templates in place of cobbler templates to allow for more robust kickstarts over time.

Stay tuned…

Creating a virtual test lab – part#3

If you've been following along, you now have a system installed and configured for creating virtual guests using cobbler. Additionally, cobbler-1.4.0 has been released. I recommend upgrading as there are numerous bug fixes and enhancements that will make life easier (and are required in my setup).

With this setup, you can do just about anything you like with your virtual guests.

  • Need a couple of dedicated systems to test some bodhi updates?
  • Check out the state of rawhide?
  • Want a disposable system to use for an upcoming Fedora Test Day?
  • Or testing out a new Fedora Live image?

I use the my cobbler setup to aid testing the installer, both manual and semi-automated. Let's start with …

Manual Installs


In this scenario, I'll configure my guests to boot the installer, but wait for me to manually walk through different use cases. For my installs, I'm going to use Fedora 10 x86_64 which I previously imported using cobbler. Also, I'll reference the virtual system names created in a previous post (e.g. vguest1, vguest2, etc…).

  1. First, create a kickstart file which we will use only to provide a location for the installation source. The $tree variable will be filled in later by cobbler.
    # echo "url --url \$tree" > /var/lib/cobbler/kickstarts/manual.ks
    
  2. Next, let's start fresh and remove any virtual guests that are running.
    # virsh destroy vguest1
    # virsh undefine vguest1
  3. Now, tell cobbler what we want to do …
    # cobbler system edit --name vguest1 \
     --profile F-10-GOLD-x86_64 \
     --kickstart /var/lib/cobbler/kickstarts/manual.ks

    Changing boot command-line arguments

    If you wish to pass any arguments to the installer, now is the time to make those changes. The –kopts option can be used to pass any kernel or installer tunables. For example, adding
    --kopts "serial console=ttyS0"

    would enable a text-mode install using ttyS0 on your guest. More information on acceptable boot options for the installer can be found at Anaconda/Options.

  4. Finally, using koan, start the install.
    # koan --server `hostname` --system vguest1 --virt
  5. If all goes well, you should be able to connect to the console of your guest.
    # virt-viewer vguest1

Using the above procedure, you can quickly initiate as many virtual installs as your system (cpu, memory and disk) can handle. Five installs at one time is about the maximum my brain can handle while remembering what I'm trying to accomplish on each system. I repeat the above steps so frequently, I include them in a small shell script for convenience.

Using my script, the above steps can be simplified with just:

# ./install-virt-guest.sh -n vguest1 -p F-10-GOLD-x86_64 -k manual.ks 

Semi-Automated Installs


A bulk of installation testing lies in understanding and using kickstart. The quickest way to get started with kickstart, is to start with a known good kickstart file. From there you can adjust the kickstart to meet your needs.

For me, a great place to look for something to automate is in the Fedora 10 installion test plan. Looking at the test plan, I see that installation using ext4 file systems is not listed. Probably something we'll want to test in the future. Let's get started …

  1. On your cobbler server, copy the sample.ks kickstart template to a new filename.
    # cp /var/lib/cobbler/kickstarts/sample.ks /var/lib/cobbler/kickstarts/ext4.ks
  2. Now edit the new file and replace the following line:
    autopart

    With something similar to the following lines:

    part /boot --fstype ext3 --size=200
    part swap --fstype swap --size=512 --grow --maxsize=2016 --recommended
    part / --fstype ext4 --size=1024 --grow
  3. That's it! Let's kick off an install on another install using our new cobbler kickstart template.
    # ./install-virt-guest.sh -n vguest2 -p F-10-GOLD-x86_64 -k ext4.ks -c "ext4" 

    Mind the command-line

    Enabling ext4 file system partitioning in Fedora 10 requires booting with an additional kernel command-line. Be sure to add ext4 to your boot parameters.

I'll leave modelling additional installs using cobbler kickstart templates for the reader. But hopefully this demonstrates how you can easily and quickly perform routine installs using cobbler kickstart templates. You may also wish to further modify your cobbler kickstart templates to meet your needs.

In my next post, I'll outline how I use SNAKE kickstart templates in place of cobbler templates to allow for more robust kickstarts over time.

Stay tuned…