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