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:[email protected]] > Sent: Wednesday, May 14, 2014 12:33 PM > To: [email protected] > 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:[email protected]] >> Sent: Wednesday, May 14, 2014 12:23 PM >> To: [email protected] >> 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 >>>
