Thanks Amila for chiming in and you hit it right. I do not think we should disrupt any fault tolerant architecture. When we discussed the FT, the focus was on single job submissions and the idea of Orchestrator sprung up as a higher level component to GFac. Following the same design, Workflow Engine needs to also sit behind Orchestrator.
The current question though is, should workflow engine be a separate service or have a simple java API which runs within Orchestrator server. Either way we keep it as a separate service or bundle it, I do not think it will not hinder andy FT strategies. But good reminder through, we need to walk through the scenarios and be definite. Suresh On Nov 5, 2014, at 12:32 PM, Amila Jayasekara <[email protected]> wrote: > Swiftly went through this thread. Seems you are going to merge workflow > service and orchestrator (if not ignore my comment). > > I remember we putting lot of thoughts to fault tolerance aspects of > Orchestrator and also workflow interpreter some time back. I do believe > merging will effect the FT design we came up at that time (Hope those design > notes are somewhere in the SGG repo) and you may need to rethink about FT > aspects. > > Thanks > -AJ > > On Thu, Oct 30, 2014 at 11:34 AM, Raminder Singh <[email protected]> > wrote: > We need to approach merging of Workflow server slightly different. Methods > like registerWorflow, getWorkflow etc need to be part of API server so client > like Xbaya need to call them remotely. I am going to get rid of workflow > server and merge methods to Airavata API server and handle launch in > Orchestrator. > > Thanks > Raminder > >>> >>> From: Shameera Rathnayaka [mailto:[email protected]] >>> Sent: Tuesday, October 28, 2014 3:56 PM >>> To: dev >>> Subject: Re: Separate Thrift services- Code restructure >>> >>> +1 for merging Workflow service with Orchestrator, >>> we are not get any advantage by keeping those two as separate services. >>> >>> Thanks, >>> Shameera. >>> >>> On Tue, Oct 28, 2014 at 4:35 PM, Raminderjeet Singh >>> <[email protected]<mailto:[email protected]>> wrote: >>> I need to move workflow sever/client out out API server to remove extra >>> dependencies on workflow model. I am going to move workflow server and >>> client to orchestrator server and can get rid of server part as next step. >>> >>> Thanks >>> Raminder >>> >>> On Tue, Oct 28, 2014 at 3:49 PM, Suresh Marru >>> <[email protected]<mailto:[email protected]>> wrote: >>> + 1. >>> >>> I think we can leave out the workflow service and its probably best to >>> embedded it with orchestrator, since there is so much overlap. So that >>> leaves 3 services: >>> >>> API Server - Client >>> Orchestrator Server -Client >>> GFac Server - Client >>> >>> Suresh >>> >>> On Oct 28, 2014, at 3:32 PM, Raminder Singh >>> <[email protected]<mailto:[email protected]>> wrote: >>> >>>> Hi All, >>>> >>>> I am fixing AIRAVATA-1471 to create separate distributions for all the >>>> Thrift services in Airavata so that we can run all in separate JVMs and >>>> dockerize (www.docker.com<http://www.docker.com>) the servers. In this >>>> exercise, i found we don’t have client stubs for several components in >>>> separate artifacts like Orchestrator Client is part of Orcherstrator >>>> Service, GFAC client is part of Orcherstator-Core, Workflow server and >>>> client is part of Airavata API server and client. To be consistent with >>>> API server and reduce maven dependency tree, i am going to create >>>> airavata— <component>—stubs package and add the component client to that >>>> project. I need to move the code and changed dependencies etc. Please let >>>> me know if there are any objections. If not i will go ahead tomorrow and >>>> make the change and commit them after testing. >>>> >>>> Thanks >>>> Raminder >>> >>> >>> >>> -- >>> Best Regards, >>> Shameera Rathnayaka. >>> >>> email: shameera AT apache.org<http://apache.org> , shameerainfo AT >>> gmail.com<http://gmail.com> >>> Blog : http://shameerarathnayaka.blogspot.com/ > >
