Skip to content

Latest commit

 

History

History
297 lines (216 loc) · 9.12 KB

chapter-infrastructure.pod

File metadata and controls

297 lines (216 loc) · 9.12 KB

Technical Infrastructure

See also the ``Getting Started Guide'' for more complete step-by-step instructions how to install the infrastructure from scratch up to a first example test run.

Adding a new host into automation

This chapter describes what you need to do in order to get a new machine into the Tapper test scheduling rotation.

Make machine remote hard resetable

Connect the machine physically to some facility to programmatically switch it completely off.

This can be the Reset cable wires connected to a dedicated reset box which can be programmed usually with an external tool. It can also be a TCP/IP controllable Power Control.

As an example Tapper comes with a plugin for the ``Infratec PM211 MIP'' ethernet controllable multi socket outlet. To use it write this in the configuration file:

reset_plugin: PM211MIP
reset_plugin_options:
  ip: 192.168.1.39
  user: admin
  passwd: secret
  outletnr:
    johnconnor: 1
    sarahconnor: 2

This configures to use the PM211MIP plugin for reset and gives it the configuration that the host ``johnconnor'' is connected on port 0 and the host ``sarahconnor'' on port 1, together with IP address, username and password of the multi-socket outlet.

If you have other hardware then write your own reset plugin FooBar in a Perl module Tapper::MCP::Net::Reset::FooBar. Look into the code of Tapper::MCP::Net::Reset::PM211MIP to get inspiration.

Machine specific configuration

Tapper configuration happens in /etc/tapper.cfg which contains everything that needs to be overwritten from the default values that come with the library Tapper::Config.

Config entries for grub can be configured for defaults like this:

mcp:
  installer:
    default_grub: |
      serial --unit=0 --speed=115200
      terminal serial
      default 0
      timeout 2
      title Test run (Install)
        tftpserver $TAPPER_TFTPSERVER
        kernel $TAPPER_KERNEL root=/dev/nfs reboot=force ro ip=dhcp \
               nfsroot=$TAPPER_NFSROOT $TAPPER_OPTIONS $HOSTOPTIONS
  test:
    default_grub: |
      default 0
      timeout 2
      title Test run (Execute)
        root $grubroot
        kernel /boot/vmlinuz root=$root reboot=force ip=dhcp noapic \
               $TAPPER_OPTIONS $HOSTOPTIONS
        $initrd_options

You can see two entries, one for the installer to boot from TFTP, and one for the actual test run after the machine was installed. Usually the second part (for test run) is defined in a precondition because it needs special needs.

In these grub entries the MCP substitutes several variables before the actual grub entry is written:

  • $grubroot

    Substituted with something like (hd0,1).

  • $root

    Substituted with something like /dev/sda2.

  • $TAPPER_TFTPSERVER

    Substituted with tfptserver IP address as configured in /etc/tapper.cfg, like:

    tftp_server_address:     165.204.15.222

  • $TAPPER_KERNEL

    Substituted with kernel image file as configured in /etc/tapper.cfg, like:

    files:
  # kernel for installer
  installer_kernel: /tftpboot/bzImage

  • $TAPPER_NFSROOT

    Substituted with NFS root filesystem as configured in /etc/tapper.cfg, like:

    paths:
   # Path to installer nfs root as set in PXE grub config
   # (IP of central host "tapper")
   nfsroot: 165.204.15.222:/data/tapper/live/nfsroot/

  • $TAPPER_OPTIONS

    Substituted with something like tapper_ip=165.204.15.222 tapper_port=1337 testrun=777777 tapper_host=tapper tapper_environment=live (as one single line), where ``tapper_ip'' and ``tapper_port'' are the host and port to send status messages to, the ``testrun'' is the testrun id of the current run, ``tapper_host'' a hostname alternative to ``tapper_ip'' and ``tapper_environment'' sets the context (``live'' or ``development'').

  • $HOSTOPTIONS

    This substitution is controlled by another entry in /etc/tapper.cfg:

    grub_completion_HOSTOPTIONS:
  _default:
    earlyprintk=serial,ttyS0,115200 console=ttyS0,115200
  capalus:
    earlyprintk=serial,ttyS4,115200 console=ttyS4,115200
  garcia:
    0xAFFE

    There you see a default value and two entries for the hosts ``capalus'' (defining a different serial interface for console) and ``garcia'' (defining something completely different without any console usage).

Make machine PXE boot aware

  • Set booting order in BIOS to network first

  • Configure DHCP for each connected machine

    The following example configures two hosts sarahconnor and johnconnor to use the respective files /tftpboot/sarahconnor.lst and /tftpboot/johnconnor.lst as grub config.

    # example dhcp config with invalid ethernet addresses
subnet 192.168.1.0 netmask 255.255.255.0 {
group
{
 filename '/tftpboot/pxegrub';
 # offer the host the here given name as host name
 option host-name = host-decl-name;
 option dhcp-parameter-request-list = concat(option dhcp-parameter-request-list,96);
 host sarahconnor
 {
   hardware ethernet 00:09:11:11:11:11;
   fixed-address 192.168.1.2;
   option configfile "/tftpboot/sarahconnor.lst";
 }
 host johnconnor
 {
  hardware ethernet 00:09:22:22:22:22;
  fixed-address 192.168.1.3;
  option configfile "/tftpboot/johnconnor.lst";
 }
}

    These grub config files are later dynamically overwritten for each boot by your application server's ``Master Control Program'' (MCP).

    The example above assumes the DHCP also running on the central Master Control Program (MCP) server. To use a DHCP server running on another host configure it with some grub/tftp redirection chains to in the end lead to the same files /tftpboot/sarahconnor.lst and /tftpboot/johnconnor.lst loaded from the MCP server.

  • Force DHCP server to reread its configuration

    $ kill -HUP $pid_of_dhcpd

Configure TFTP on central MCP machine

The MCP server is also acting as a TFTP server, so it has to be configured as such:

  • Install a TFTP server

    $ sudo apt-get install inetutils-inetd
$ sudo apt-get install atftpd
$ sudo chmod 777 /var/lib/tftpboot/
$ sudo ln -s /var/lib/tftpboot /tftpboot

  • Create symlinks to point TFTP dir into Tapper working dir

    The TFTP daemon only serves files from /tftpboot, as seen above in the DHCP config. To supply files from the Tapper working dir make the /tftpboot a symlink to the Tapper working dir.

    $ ln -s /data/tapper/live/configs/tftpboot /tftpboot

    When Tapper creates tftp files it works with absolute path names. Because the TFTP daemon interprets all absolute pathnames relative to its root dir we supply a tftpboot symlink inside the tftp root (which is also our Tapper working dir), so we can use the same absolute path name in both contexts (Tapper and TFTP):

    $ ln -s /data/tapper/live/configs/tftpboot \
        /data/tapper/live/configs/tftpboot/tftpboot

Make the hosts known in the TestrunDB

$ tapper host-new --name=sarahconnor --active=1
$ tapper host-new --name=johnconnor  --active=1

This makes the hosts generally available (active) for scheduling testruns by machine name. For scheduling hosts by more detailed machine features (cpu, memory, family, etc.) you need to add according key/value pairs in the HostFeature table.

Optionally: enable temare to generate tests for this host

Temare is an utility that generates preconditions according to a test matrix of host/guest virtualization scenarios (but not yet shipped publicly).

For generating preconditions for a host, you can register the host in temare.

If you want tests scheduled for the new machine then follow these steps:

  • Login as root on MCP server

  • Set the PYTHONPATH to include the temare src directory

    export PYTHONPATH=$PYTHONPATH:/opt/tapper/python/temare/src

  • Add the host to temare hostlist

    $ /opt/tapper/python/temare/temare hostadd $hostname \
                                            $memory \
                                            $cores \
                                            $bitness

Optionally: Web server for autoinstall

If you want to use autoinstall (i.e. kickstart, autoyast in contrast to image based installation with the Tapper installer) the suggested way to do it is Cobbler. If you do not want to use Cobbler, Tapper also supports kickstart more directly using the autoinstall precondition type. For this precondition you need a way to get the kickstart/autoyast to the test machine. The suggested way is a Web server, e.g Apache. Adapt your Apache config with the following: cat <<EOF >>/etc/apache2/conf.d/tapper.conf Alias /autoinstall /data/tapper/live/configs/autoinstall <Directory /data/tapper/live/configs/autoinstall> Options +FollowSymLinks +Indexes ForceType text/plain order allow,deny allow from all </Directory> EOF

  • Add the Tapper ssh key to your image.

    cat /home/tapper/.ssh/id_dsa.pub >> /root/.ssh/authorized_keys

    (FIXME) Actually this does not belong into the host preparation but into a separate image preparation chapter which does not yet exist.

POD ERRORS

Hey! The above document had some coding errors, which are explained below:

Around line 269:

You forgot a '=back' before '=head3'

Around line 289:

'=item' outside of any '=over'