Harness

Update the Harness command line driver to add options to control other SessionSettings from command line parameters (not just userid/password as we have today).

Discussion from #2104:

CA (note 48)
Greg, I'm trying to make the harness to auto-configure by using "<<HERE_DOCUMENT" passed to the java command, like this:

java <options-to-start-harness-here> <<HERE_DOCUMENT!
val1
val2
val3
HERE_DOCUMENT

host (can default to localhost and not read it at all)
ssh-port (can default to 22 and not read it at all)
username (must be sent as $USER)
password (must be read from a prompt)
MAJIC installation folder (can default to ~/testing/majic and not read it at all)
GSO instance number (must be sent and needs to be computed)
RFQ instance number (must be sent and needs to be computed)
shell prompt text (can default to devsrv01 and not read it at all)
psql port (must be sent and needs to be computed)

GES (note 55)

the harness uses System.console() internally to read the data... as the input is redirected, System.console() is null and thus no data is read. Should I go ahead and fallback to reading from System.in if no console exists?

That does seem like a good change to make. But I am hoping you can implement a better solution than using HERE_DOCUMENTs.

host (can default to localhost and not read it at all)
ssh-port (can default to 22 and not read it at all)
username (must be sent as $USER)
password (must be read from a prompt)
MAJIC installation folder (can default to ~/testing/majic and not read it at all)
GSO instance number (must be sent and needs to be computed)
RFQ instance number (must be sent and needs to be computed)
shell prompt text (can default to devsrv01 and not read it at all)
psql port (must be sent and needs to be computed)

Please see #1552. This task would handle some of your requirements, but you also need to be able to initialize user-variables. I am OK with updating the harness command line driver to allow both kinds of parameters to be passed. I think this is the cleanest way to do it. Since we are the only user of this so far (and the only usage is for TIMCO), we don't even have to maintain command line compatibility if there is a good reason to do it differently. I think this is the best way. You can calculate all the values needed in the script (or not if they should default) and then pass them on the command line when you launch the harness.

CA (from note 56)

Please see #1552. This task would handle some of your requirements, but you also need to be able to initialize user-variables.

My approach would be to add a -v option ("v" from "variable") which can appear multiple times and will be a "key=value" pair to define a certain variable. This would work like -v instanceNum=20 -v instanceRfqNum=30 to set the instanceNum and instanceRfqNum variables. Internally, when the harness needs to read a variable, it will first check if was not set via an argument: if it was, it will read it from there; else, from the console. This way, we don't need to fork/alter the test definition files in the baseline, will be just a change in the harness.

GES (note 57)

My approach would be to add a -v option ("v" from "variable") which can appear multiple times and will be a "key=value" pair to define a certain variable. This would work like -v instanceNum=20 -v instanceRfqNum=30 to set the instanceNum and instanceRfqNum variables. Internally, when the harness needs to read a variable, it will first check if was not set via an argument: if it was, it will read it from there; else, from the console. This way, we don't need to fork/alter the test definition files in the baseline, will be just a change in the harness.

I like it. You will have to do something similar (but different) for the session settings (e.g. hostname, port...), right?

CA (note 58)

You will have to do something similar (but different) for the session settings (e.g. hostname, port...), right?

• -h - set the host
• -p - set the port
• -u - set the userid
• -w - set the password

But, setting the password via an argument will expose it in the process list returned by i.e. ps aux; this can pose security problems.

GES (note 59)

But, setting the password via an argument will expose it in the process list returned by i.e. ps aux; this can pose security problems.

Understood. Add it as an option, but we should document the security hole.

For our purposes, we probably do need to:

1. Fix the stdin issue so that the password can be read interactively even when the console is redirected.
2. Test out key-based authentication so no password would be needed.

Code Feedback:

1. What about the fallback option to use System.in instead of the console?

2. Please update the docs/harness.html section on "Running the Harness" with the new command line syntax.

Otherwise the changes look good.

The code updates are all good. In the harness.html, please add yourself to the author list at the top, update the date and increment the harness version to 1.1.

Then you can check in the update. Only Stanislav and Eugenie need to be notified (copy Eric and myself) via email. Please tag the checked in version with "v1.1_20130411".

I assume there are no compatibility issues with shifting to this? But if there are some differences, please inform us in the email.