Thanks Chathuri, the new changes look good. I will recommend another field for input validation. It can be used to validate user input based on text comparison or regex. We can extend the orchestrator validator to use the field to validate inputs.
I am not completely able to understand the use of inputMetadataType. Metadata normally contain extra information about the data or a validation schema etc. If we restrict inputMetadataType to ENUM its can become very specific to one application, Gaussian in this case. I am not able to understand the use of converting metaData to inputMetadataType map. I will recommend similar changes to output schema (see AIRAVATA-1544). Thanks Raminder On Dec 8, 2014, at 10:22 AM, Chathuri Wimalasena <[email protected]> wrote: > Hi Devs, > > We are trying to add Gaussian application using airavata-appcatalog. While > doing that, we face some limitations of the current design. > > In Gaussian there are several input files, some input files should used when > the job run command is generated, but some does not. Those which are not > involved with job run command also need to be staged to working directory. > Such flags are not supported in current design. > > Another interesting feature that in Gaussian is, in input file, we can > specify the values for memory, cpu like options. If input file includes those > parameters, we need to give priority to those values instead of the values > specified in the request. > > To support these features, we need to slightly modify our thrift IDLS, > specially to InputDataObjectType struct. > > Current struct is below. > > struct InputDataObjectType { > 1: required string name, > 2: optional string value, > 3: optional DataType type, > 4: optional string applicationArgument, > 5: optional bool standardInput = 0, > 6: optional string userFriendlyDescription, > 7: optional string metaData > } > > In order to support 1st requirement, we introduce 2 enums. > > enum InputValidityType{ > REQUIRED, > OPTIONAL > } > > enum CommandLineType{ > INCLUSIVE, > EXCLUSIVE > } > > Please excuse me for names. You are welcome to suggest better names. > > To support 2nd requirement, we change metaData field to a map with another > enum where we define all the metadata types that can have. > > enum InputMetadataType { > MEMORY, > CPU > } > > So the new InputDataObjectType would be as below. > > struct InputDataObjectType { > 1: required string name, > 2: optional string value, > 3: optional DataType type, > 4: optional string applicationArgument, > 5: optional bool standardInput = 0, > 6: optional string userFriendlyDescription, > 7: optional map<InputMetadataType, string> metaData, > 8: optional InputValidityType inputValid; > 9: optional CommandLineType addedToCommandLine; > 10: optional bool dataStaged = 0; > } > > Suggestions are welcome. > > Thanks, > Chathuri >
