airavata-dev mailing list archives

Site index · List index
Message view « Date » · « Thread »
Top « Date » · « Thread »
From Marlon Pierce <marpi...@iu.edu>
Subject Re: Validation failures and storing the failures
Date Wed, 14 May 2014 20:27:00 GMT
Ah, I see what you mean. This should definitely be logged by Airavata as
well. I don't think we need more sophisticated storage.

Marlon

On 5/14/14 3:42 PM, Miller, Mark wrote:
> 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 purposes. 
>
> -----Original Message-----
> From: Marlon Pierce [mailto:marpierc@iu.edu] 
> Sent: Wednesday, May 14, 2014 12:33 PM
> To: dev@airavata.apache.org
> 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.
>
> Marlon
>
> 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 [mailto:marpierc@iu.edu]
>> Sent: Wednesday, May 14, 2014 12:23 PM
>> To: dev@airavata.apache.org
>> 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]
>>> https://docs.google.com/document/d/1FOc0X6HCMZ9E-fTnZQ8aGo7tK20C8lvKl
>>> y
>>> cNouswICI/edit
>>>
>>> Regards
>>> Lahiru
>>>


Mime
View raw message