airavata-dev mailing list archives

Site index · List index
Message view « Date » · « Thread »
Top « Date » · « Thread »
From Marlon Pierce <marpi...@iu.edu>
Subject Re: Orchestrator and Airavata API changes
Date Fri, 24 Jan 2014 19:33:46 GMT
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.

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
>


Mime
View raw message