Mailing-List: contact dev-help@airavata.apache.org; run by ezmlm
Precedence: bulk
Reply-To: dev@airavata.apache.org
Received-SPF: pass (nike.apache.org: local policy)
Message-ID: <5373D194.9070302@iu.edu>
Date: Wed, 14 May 2014 16:27:00 -0400
From: Marlon Pierce <marpierc@iu.edu>
User-Agent: Mozilla/5.0 (Macintosh; Intel Mac OS X 10.6;
 rv:24.0) Gecko/20100101 Thunderbird/24.5.0
MIME-Version: 1.0
To: dev@airavata.apache.org
Subject: Re: Validation failures and storing the failures
References: 
 <CAKq9_6JQbr0BiOUMtYRa=T_qZSJDTZAPkjho49RDpiu+Va_R8g@mail.gmail.com>
 <5373C2A9.9070103@iu.edu>
 <D8081195C7EF5A458FE73665B960FC34349D5F33@XMAIL-MBX-BT1.AD.UCSD.EDU>
 <5373C4D4.2000304@iu.edu>
 <D8081195C7EF5A458FE73665B960FC34349D6016@XMAIL-MBX-BT1.AD.UCSD.EDU>
In-Reply-To: 
 <D8081195C7EF5A458FE73665B960FC34349D6016@XMAIL-MBX-BT1.AD.UCSD.EDU>
Content-Type: text/plain; charset=ISO-8859-1
Content-Transfer-Encoding: 8bit

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
>>>