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
