You can write any Traffic Server config file by adding a section to the string you pass to TestExec::pm_create_instance under the config section. All the details are at here. Here's a general example config string:
[records.config] proxy.config.diags.output.status SE proxy.config.diags.output.note SE proxy.config.diags.output.warning SE proxy.config.diags.output.error SE proxy.config.cache.storage_filename storage.config proxy.config.proxy_name deft.example.com proxy.config.hostdb.size 50000 add CONFIG proxy.config.core_limit INT -1 [foobar.config] This text will appear in config/foo.bar.config
To tell the TS where another service is (for example, jtest for a reverse proxy), start up that service first. Then use a %%() substition of a port binding from that service in a appropriate place in jtest.config. An example test case that does exactly this is jtest-revproxy.pl.
There is a script and a Makefile target to automatically do this. It's available in the source tree at traffic/test/deft_package_ts.pl. From the test directory, you can use:
gmake pkg_ts
which will create Traffic Server package in traffic/deft-install/packages.
If you want to package a release engineering build or any other build tree without running the Makfile target:
deft_package_ts.pl -b <top of build area>
Currently, you must package on the same architecture as the TS was built on.
While DEFT is completely capable of using TS packages, most existing scripts set localpath for Traffic Server to %%(ts_localpath). I've modified the example scripts to only set localpath for TS if %%(ts_localpath) has been set but other tests will need to be converted.
In order not to have run_test.pl automatically set ts_localpath, do not pass the traffic_server build as the first argument.
First look at the test log. Depending on the parser for the package, you may get the releveant part of the test log dumped as an error or warning after the test has finished. If you are not seeing an error or warning, go look at the raw test log. You can get access to it either through the graphic log viewer which is invoked by starting run_test.pl with '-v' or by looking in /inktest/<username>-0/log/test.log.
If you still don't see anything helpful, run the test with some debug tags on in the test executor. The most helpful one usually is raf. Debug tags are invoked the same way they are for Traffic Server, using the '-T' option. For raf, pass '-T raf' to run_test.pl.
If you still can not tell what the problem, try starting up your installed test packages by hand. Deft does not delete an instance directory until you run another test so it's easy to inspect and try to run your test process. Just cd to /inktest/<username>-0/run/<instance_name>. Then run your test process manually. Don't forget to use an arguments that test script would start up the process with.
At this step, we are pulling out the heavy artillery. We want to run the components of DEFT manually so we can get debug tags from the proc_manager and run dbx on the proc_manager if necessary. The first thing you need to do is start up all the proc_managers manually. This is much easier to do if you are running your test on localhost as you only have one start up. To start the proc_manager manually with all debug tags on (use your own base port and substitute a different architecture suffix if not running on sparc):
cd /inktest/<username>-0/ ./proc_manager-SunOS -p 12400 -d . '-T.*'
If you don't want the debug tags, leave off '-T.*'. In another window, start your test as you normally would but add '-m'. For example:
./run_test.pl -p 12400 -s jtest-example.pl -m
You won't have a log collator when starting up manually. If you want to look at the log it will be in /inktest/<username>-0/log/log.<proc_manager.pid>.
Starting up the components manually is really the keys to the kingdom since it allows you start any component. You can run the log collator if you want to as well, but starting it manaully and using the '-L' option to the proc_manager to tell it where the log_collator is running.