airavata-dev mailing list archives

Site index · List index
Message view « Date » · « Thread »
Top « Date » · « Thread »
From "Miller, Mark" <>
Subject RE: Validation failures and storing the failures
Date Wed, 14 May 2014 19:42:00 GMT
Remember, I am on the naïve side so I am not saying what should be in terms of implementation.
Certainly, passing to the Gateway for storage in the Gateway database is a good solution for
the Gateway.

I was wondering if the Airavata operators might need access to the same information, for debugging

-----Original Message-----
From: Marlon Pierce [] 
Sent: Wednesday, May 14, 2014 12:33 PM
Subject: Re: Validation failures and storing the failures

I was assuming the gateway would figure out what to do with the errors after step 4.  This
obviously needs more thought on how this would work.


On 5/14/14 3:27 PM, Miller, Mark wrote:
> I feel as long as they are stored somewhere, that should be fine.
> The question is, if Airavata doesn't have access to the gateway database, will they be
hamstrung by the inability to retrieve failure messages that might be informative?
> Maybe everything will be in the logs anyhow?
> Mark
> -----Original Message-----
> From: Marlon Pierce []
> Sent: Wednesday, May 14, 2014 12:23 PM
> To:
> Subject: Re: Validation failures and storing the failures
> I don't think these need to be stored, just sent back to the gateway. 
> If I recall correctly, steps are
> 1. Gateway invokes "execute" method of API server.
> 2. API Server runs Orchestrator's "validate()".
> 3. Orch returns result of validation.
> 4. API server returns results to the gateway.
> 5. If validation passed, API Server then runs the Orchestrator's "launch()".
> So step #4 should enough.
> Marlon
> On 5/14/14 12:17 PM, Lahiru Gunathilake wrote:
>> Hi All,
>> We recently added validation logics to orchestrator, so gateway 
>> developers can add/configure their validators to be invoked. If they 
>> failed they can wrap an error message in their validation logic and return that.
>> Orchestrator needs to take these error messages and store them to a 
>> persistent storage so that if the validation failed these errors can 
>> be showed to the gateway user to make it correct. Unless we give a 
>> proper error message to the end user there is no way to make it correct.
>> Currently in the orchestrator implementation it does not store the 
>> error but we have a proper result object which keeps the validation 
>> state and a message.
>> Where should I save this information in our data model ? This is an 
>> information specific to each invocation and there could be multiple 
>> error messages came from multiple validators because we do not return 
>> immediately after the first validation failure but rather we invoke 
>> all the validators and collect all the errors (currently we just have 
>> access to them and simply logging those errors in server side). If 
>> there is no placeholder for these validation errors can we add 
>> something to the data model to store them and retrieve them from the client code
>> I have added FAQ type of a document for Orchestrator[1], please 
>> provide your feedback on this.
>> [1]
>> y
>> cNouswICI/edit
>> Regards
>> Lahiru

View raw message