Present: Marc Paterno, Amber Boehnlein, Wyatt Merritt (notes), Jim Kowalkowski, Harry Melanson, Alan Jonckheere, Paul Russo, Roger Moore, Greg Graham, Dhiman Chakraborty
In the meeting, we discussed a proposal by Marc and Jim to handle the concept of transient information included in RCP files; i.e., information such as debug flags controlling the amount of output or integers specifying the number of events to be read or to have printout turned on. This sort of information, while often convenient to include in the same files which configure algorithms and certainly convenient to read in with the RCP parser, is very inconvenient when it is tracked in the database and unnecessarily causes RCPIDs to change. This proposal is rather new and the exact syntax and implementation rules are not fixed. The basic idea is that users would be able to include three new data types in an RCP file, called something like untracked or transient, along the lines of
untracked bool debug_flag = true
untracked int number_of_events = 5
untracked string file_for_error_logging = 'error.dat'
Parameters specified in this way in an RCP script would not be put into the RCP database or included in the hash codes for checking RCP equality. If an RCP containing transient parameters were read from the database, the transients would be provided from defaults in the program. It was mentioned that the farm jobs would get all RCPs from the database, not from scripts, so developers should ALWAYS MAKE THE DEFAULT SUITABLE FOR THE FARM (for example, debug outputs should be off by default). It is possible to have an RCP file which consists solely of transient parameters. Such a file would look "empty" to the database, and would get a special RCPID, one which we would never expect to see attached as the RCPID for a chunk. One potential use for this is the framework RCP, which contains information that should be transient as far as the RCP database is concerned (although we should have a mechanism for tracking this information as SAM metadata at the project level).
A further proposal came from Roger Moore to enhance this by giving the user interested only in running an executable a way to specify only the transient parameters without checking out and editing the whole rcp. The meeting liked the proposal, but since it remains to be checked if it can work with all the multiple cases of RCP use, I won't try to describe it here. If it proves feasible, it will be included in the documented proposal later.
A feature of this proposal is that current RCP files will continue to
work, even if they include as permanent parameters things which "should"
be transient, like debug flags. We rely on the inconvenience of having
your rcpid change for trivial reasons to persuade users to make use of
the transient mechanism to specify those parameters for which tracking
is unnecessary. When they change a parameter in an existing RCP file
to transient, they will also have to change the code which extracts that
parameter, and provide a default.