On Jan 24, 2014, at 2:33 PM, Marlon Pierce <[email protected]> wrote: > I am +1 for the approach. It will be interesting to see if the Java code > generated from Thrift (third bullet) plays well with OpenJPA in the > registry. I'm sure other tricky details will come up as we work on this.
Great. Over rest of day, I will create JIRA tasks and draft up some data models, please comment on the JIRA and its subtasks to we the discussion will have one stop place to review all iterations of the data model - https://issues.apache.org/jira/browse/AIRAVATA-991 Suresh > > Marlon > > On 1/24/14 2:19 PM, Suresh Marru wrote: >> Hi All, >> >> While drafting the thrift IDL for airavata api and in offline discussions, >> we have identified some ambiguity and convolution in the way we are >> integrating orchestrator and plugging in airavata api. It will be better to >> straighten this now. Here are some observations, please provide feedback so >> we can decide on how to act on these. >> >> * Currently the Orchestrator SPI has create experiment methods. It will be >> better if the airavata api can pass through these functions directly to >> registry and only make a call to orchestrator during launch of the >> experiment. >> >> * Airavata clients query the registry for fetching results produced by the >> executions and to find the status of executions. The registry SPI provides >> these capabilities implemented by the provenance catalog (experiment >> tables). Currently we are storing information in orchestration tables. It >> will be good if we can keep all experiment related data (clients will be >> interested in) in provenance side of registry. It will be better if we limit >> the use or orchestrator tables only for system internal debugging/fault >> tolerance/recovery information. This means that orchestrator to recover from >> failures, will only have to pull information from provenance side (to >> understand the original request and status) and use the orchestrator table >> information for finer grained details (which are of not interest to the >> clients). >> >> * Given that we are moving foreword with thrift as a release feature (from >> the initial viability experiment), it will be better if we resuse the thrift >> generated data model internally within airavata as well. That means we can >> treat the registry as the object store (objects defined by thrift idl’s) and >> internal components will populate these model objects in favor or local >> models. This will firstly help keep all the information in sync and also >> avoid proliferation of model objects. >> >> Comments and thoughts on these changes? >> >> I will draft up a experiment model and send for feedback. >> >> Suresh >> >
