Hi All,
After the discussion with Upeksha, we decided to implement Airavata
Workflow as a part of the current Experiment. With that, it is required to
modify the current way of saving output files and reporting execution
errors at Process execution level.
I modified the previous workflow
Hi Marcus and Sudhakar,
Thank you for the detailed answers but still, I have few issues. Let me
explain a little bit more about the architecture of the Airavata Workflow
implementation.
[image: workflow.png]
Currently, Orchestrator is only capable of submitting single application
Experiments.
On Sep 20, 2018, at 12:15 AM, Yasas Gunarathne
mailto:yasasgunarat...@gmail.com>> wrote:
In the beginning, I tried to use the current ExperimentModel to implement
workflows since it has workflow related characteristics as you have mentioned.
It seemed to be designed at first keeping the
Yasas and Marcus:
Please see below..
On Sep 20, 2018, at 12:15 AM, Yasas Gunarathne
mailto:yasasgunarat...@gmail.com>> wrote:
Hi Marcus,
Thank you very much for the suggestion.
In the beginning, I tried to use the current ExperimentModel to implement
workflows since it has workflow related
Hi Marcus,
Thank you very much for the suggestion.
In the beginning, I tried to use the current ExperimentModel to implement
workflows since it has workflow related characteristics as you have
mentioned. It seemed to be designed at first keeping the workflow as a
primary focus including even
On Sep 8, 2018, at 9:11 AM, Yasas Gunarathne
mailto:yasasgunarat...@gmail.com>> wrote:
To represent workflow application -> process relationship, it is required to
fill the experiment_id field of the process with a null and then add an entry
to an intermediate table to keep the above
Hi Upeksha,
I will change my implementation [1] accordingly.
[1]
https://github.com/apache/airavata/compare/develop...yasgun:ochestrator-refactoring
Thank You
On Sat, Jul 7, 2018 at 10:09 PM DImuthu Upeksha
wrote:
> Hi Yasas,
>
> I my preference is to go with first approach. It looks simple
Hi All,
Thank you for the information. I will consider the explained scenarios in
the process of modifying the Orchestrator with workflow capabilities.
Apart from that, I have few issues to be clarified regarding the API level
implementation. *ExperimentModel* has *ExperimentType* enum which
Some times the workflow crashes and/or ends unfinished which is probably more
like scenario 2. In those cases also one has to restart the workflow from the
point where it stopped.
So a workflow state needs to be maintained along with the data needed and where
it might be available when a
Hi Yasas,
Thanks for the summary. As now you have a clear idea about what you have to
do, let's move on to implement a prototype that validates your workflow
blocks so that we can give our feedbacks constructively.
Hi Sudhakar,
Based on your question, I can imagine two scenarios.
1. Workflow
Is there a chance to include workflow restarter (where it was stopped earlier)
in the tasks.
Thanks,
Sudhakar.
On Jun 2, 2018, at 11:52 PM, Yasas Gunarathne
mailto:yasasgunarat...@gmail.com>> wrote:
Hi Suresh and Dimuthu,
Thank you very much for the clarifications and suggestions. Based on
Hi Suresh and Dimuthu,
Thank you very much for the clarifications and suggestions. Based on them
and other Helix related factors encountered during the implementation
process, I updated and simplified the structure of workflow execution
framework.
*1. Airavata Workflow Manager*
Airavata
Hi Yasas,
I'm not a expert in XBaya design and use cases but I think Suresh can shed
some light about it. However we no longer use XBaya for workflow
interpretation. So don't get confused with the workflows defined in XBaya
with the description provided in the JIRA ticket. Let's try to make the
13 matches
Mail list logo
