Description of problem: The HOSTNAME parameter is not passed on to the /distribution/inventory task. The hostname is set by something else (either the shell, which is bash or included scripts). Version-Release number of selected component (if applicable): 1.2-4 (Beaker 25) How reproducible: 100% Steps to Reproduce: 1. Schedule a system scan and set the task parameter to something nonsensical. E.g.: <task name="/distribution/inventory" role="STANDALONE"> <params> <param name="HOSTNAME" value="foobar"/> </params> </task> 2. See it use a different hostname. Actual results: "Ignores" the HOSTNAME parameter Expected results: Should use the HOSTNAME parameter Additional info: Beah actually invokes the task with the task parameter set as the environment.
Does that mean when we implemented this in bug 1438666 it never actually did anything?
Seems to the case. The environment in beah is correctly set, but somewhere in between the HOSTNAME set get's lost/overwritten. I've tested with a small reproducer to run a shell script in which I print the host name using a simple custom protocol from twisted. The script correctly printed my hostname I passed as the environment. Are the tests running in a separate shell, that the shell could ignore/overwrite the HOSTNAME perhaps?
I also thought about simply setting the hostname with '-f' in the inventory task (like in comment 3 Bug 1438666), but the sad truth is that a hostname is set when the task is run. It's just the unqualified name ...
I looked into this. Went aaaaaaall the way down the rabbit hole which beah is. The chain seems to look like this: * beah generates an executable Bash script with a random file name in /mnt/testarea * This is executed with the correct environment from the task, which in turn passes this on to beah-rhts-task * beah-rhts-task is a Python script (file is: rhts_xmlrpc.py) which executes another wrapper Bash script called beah-rhts-runner.sh asynchronously via twisted. The execution happens in a Bash login shell and here is where most of the environment gets lost including the host name. * beah-rhts-task also exports the environment as a JSON file For completeness: * beah-rhts-runners.sh is not the actual test runner. It does compatibility checks and - the job I introspected - calls tortilla. * Tortilla is a Python script which seem to call bash scripts in a certain order and one of them is 'runtest' * runtest is a Bash script which calls 'rhts-test-runner.sh' and invokes the next after that (for tortilla) * rhts-test-runner.sh is almost the last piece of the puzzle since it actually now calls the Makefile of the task, collects logs etc. One thing I couldn't verify yet is if at some point in this whole chain the written environment file is read again by one of those scripts. I doubt it, but I'll check if it's true.
Spoke to dcallagh about what to do about this. A quick fix could be to not use a login shell which would carry over the environment. Yet this can have unforeseen consequences and in the light of restraint and the fact that it's possibly only related to the HOSTNAME not really worth doing. The possible negative impact would just be too big. Instead I've re-scheduled the job against Beaker 25.0 to use the changes from Bug 1438666 which solves the problem without having to deal with beah. In that sense I'll move this bug to WONTFIX.