====== Daniel Verkamp: Automated regression testing ======

===== Journal Week 9 =====

==== Monday, July 20 ====

Implemented configuration file loading for Test::Machine, as discussed with Michael.

Configuration file syntax:

  key = value
  # comment

Trailing comments on ''key = value'' lines are currently not supported to allow for arbitrary value content.
Leading and trailing whitespace on ''key'' and ''value'' is trimmed.

Usage example:

  use Test::Machine;
  my $machine = Test::Machine->load ( "config" );

Current configuration options supported:

  * ''type'': currently only ''QEmu''
  * ''hdd''/''fdd''/''cdrom'' followed by index (ex ''hdd0''): value is filename (ex ''server.hd'')
  * ''nic'': followed by index, period, and sub-option (ex ''nic0.type''); suboptions are those supported by given machine type
  * ''snapshot'': snapshot filename to load

See commit in [[http://git.etherboot.org/?p=people/dverkamp/gpxe.git;a=shortlog;h=refs/heads/testsuite|git]].

==== Tuesday, July 21 ====

In preparation for console read/write support in the QEMU driver, I switched the QEMU monitor interface over from using STDIN/STDOUT to a PTY.  This will allow ''-curses'' to use the usual handles while the monitor is also in use.  [[http://git.etherboot.org/?p=people/dverkamp/gpxe.git;a=shortlog;h=refs/heads/testsuite|git]]

==== Wednesday, July 22 ====

Attempt at writing a console() function for Machine::Qemu using the ''-curses'' option; first step in this, attaching an IO::Pty to the monitor interface, was completed yesterday.  However, once the ''-curses'' option is added, the monitor PTY no longer gets the ''(qemu)'' prompt it expects.  Some other methods (-nographic and -serial stdio) also attempted, but these don't do actual console redirection, only serial.

==== Thursday, July 23 ====

Set console() to the side for now; attempting to debug the snapshot DHCP server problems (the server snapshot starts up but the client does not get a DHCP reply).  It seems that the snapshot generally works right after it is taken, but not after some time (generally several days) has passed.  My new theory is that there is some problem with the system clock of the VM with the snapshot when it is started up later, causing the DHCP server to get confused, but I don't know how to diagnose that for sure.  It is difficult to narrow down the conditions that reproduce the problem, but seemingly once a snapshot fails to work, it continues to fail on any further attempts.