airavata-dev mailing list archives

Site index · List index
Message view « Date » · « Thread »
Top « Date » · « Thread »
From Suresh Marru <>
Subject Re: Orchestrator and Airavata API changes
Date Fri, 24 Jan 2014 19:52:51 GMT
On Jan 24, 2014, at 2:33 PM, Marlon Pierce <> 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 -


> 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

View raw message