Hi Mark, Yes its definitely logged in airavata logs and we are hoping to pass them to the gateway.
Lahiru On Wed, May 14, 2014 at 3:59 PM, Danushka Menikkumbura < [email protected]> wrote: > Yes. I think the error information needs to be exposed. Especially when it > comes to long-running operations where recreating an issue would likely to > be a bit of a hassle. > > /Danushka > > > On Thu, May 15, 2014 at 1:12 AM, Miller, Mark <[email protected]> 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 >> >> >> >> > -- System Analyst Programmer PTI Lab Indiana University
