Hi Shabhaz, Yes, I am about to do that, I just have one more task to finish this work, once I am done, will remove the old code from trunk.
Regards Lahiru On Tue, Feb 19, 2013 at 6:28 AM, Shahbaz Memon <[email protected]>wrote: > > If you want to understand the new architecture by looking in to the code, > > please just refer the package org.apache.airavata.gfac, do not refer any > of > > the classes in org.apache.airavata.core.gfac. > > IMHO the unused or outdated code should be moved to any temporary > branch, so that people checking-out trunk would get the actual/latest > source of the architecture realization. In that sense it will not be a > problem for devs if later the outdated code is reused. > > Cheers, > > Shahbaz > > On Mon, Feb 18, 2013 at 8:59 PM, Lahiru Gunathilake <[email protected]> > wrote: > > Hi Sanjaya, > > > > If you want to understand the new architecture by looking in to the code, > > please just refer the package org.apache.airavata.gfac, do not refer any > of > > the classes in org.apache.airavata.core.gfac. > > > > Best place to start with is referring is from test classes > > (LocalProviderTest,GramProviderTest), from tehre you can start looking in > > to GFacAPI class and see how to execution is flawing. > > > > if you have further questions please post on the list and more than happy > > to help. I will be doing some documentation about the architecture, once > I > > am done, will post in to the list. And we will be having an architecture > > review this week, so please watch the mailing list, if possible please > try > > to join us. > > > > Regards > > Lahiru > > > > On Mon, Feb 18, 2013 at 1:25 PM, Sanjaya Medonsa <[email protected] > >wrote: > > > >> Thanks Suresh and Chris! It seems I am moving on the correct path. I > have > >> followed the email thread on improved GFac architecture. Though I am not > >> entirely clear on the improved GFac architecture, proposed integration > with > >> OODT is primarily based on the GFac extension, PreExecustionChain, which > >> has not been modified with the Architecture improvements (As per one of > the > >> replies from Lahiru, output extension is supported with new > Architecture. I > >> assume input extension is also supported). > >> > >> I have looked into provenance manager and related implementation. Still > I > >> am unclear how Airavata support provenance aware work flow processing. > >> > >> Best Regards, > >> Sanjaya > >> > >> On Mon, Feb 18, 2013 at 6:35 AM, Suresh Marru <[email protected]> > wrote: > >> > >> > Hi Sanjaya, > >> > > >> > This sounds very exciting. Both Airavata and OODT projects have good > >> > synergies and have been long looking for volunteers who can bridge > them > >> > both. Please do not hesitate to ask any questions to either or both > the > >> dev > >> > lists. The more engaged you are, you will find use cases and feedback > >> which > >> > should help your MSc project. > >> > > >> > Your plan sounds good. If you are following dev list, you may have > >> > noticed, the GFac architecture has been improved to properly support > this > >> > kind of handler architecture. > >> > > >> > You may also want to look at Airavata Registry API which has > organically > >> > emerged with the need, but can greatly benefit for OODT's provenance > >> > capabilities. > >> > > >> > Suresh > >> > > >> > On Feb 17, 2013, at 1:25 PM, "Mattmann, Chris A (388J)" < > >> > [email protected]> wrote: > >> > > >> > > +1, sounds like a great idea Sanjaya! > >> > > > >> > > I'm copying dev@oodt so they can be in the conversation too. > >> > > > >> > > Cheers, > >> > > Chris > >> > > > >> > > On 2/17/13 10:22 AM, "Sanjaya Medonsa" <[email protected]> > wrote: > >> > > > >> > >> Hi Dev Team, > >> > >> As I have posted previously, I am working on a Apache Airavata + > >> Apache > >> > >> OODT integration as my MSc project. Following is one of the > possible > >> > >> integration to leverage Apache OODT file management capability into > >> > Apache > >> > >> Airavata. Please review the proposal and let me know your feedback. > >> > >> > >> > >> Proposal To Use Apache OODT products as input to Apache Airavata > >> > Workflows > >> > >> and staging product files into node where execution happens > >> > >> > >> > > >> > ========================================================================== > >> > >> ============================== > >> > >> 1. Introduce "Apache OODT Product" as a new GFacParameterType. New > >> > "Apache > >> > >> OODT Product" input type can sepcify "Product ID" or "File Path to > >> > >> Product" > >> > >> as an input to Apache Airavata workflows. > >> > >> 2. Introduce new PreExecuteChain to retrieve Apache OODT Products > from > >> > >> File > >> > >> Manager Server managed using Apache OODT. > >> > >> 1. Using Apache OODT File Manager componenet transfer Product from > >> > Server > >> > >> to input directory of the application as configured using XBaya-GUI > >> > under > >> > >> advanced configuration. (Here the assumption is that Products are > >> > >> accesible > >> > >> through Apache OODT File Manager server) > >> > >> 2. Finally reset the input value to local file path. I think we can > >> > remove > >> > >> the OODT Product parameter from invocation context and add new file > >> > >> parameter with value set to 'local path of the transferred > product'. I > >> > am > >> > >> not quite sure what are the implications of changing input > parameter > >> > type > >> > >> during the execution. > >> > >> > >> > >> Similar approach has been implemented for GridFTP and HTTP. > >> > >> > >> > >> Best Regards, > >> > >> Sanjaya > >> > > > >> > > >> > > >> > > > > > > > > -- > > System Analyst Programmer > > PTI Lab > > Indiana University > > > > ------------------------------------------------------------------------------------------------ > > ------------------------------------------------------------------------------------------------ > Forschungszentrum Juelich GmbH > 52425 Juelich > Sitz der Gesellschaft: Juelich > Eingetragen im Handelsregister des Amtsgerichts Dueren Nr. HR B 3498 > Vorsitzender des Aufsichtsrats: MinDir Dr. Karl Eugen Huthmacher > Geschaeftsfuehrung: Prof. Dr. Achim Bachem (Vorsitzender), > Karsten Beneke (stellv. Vorsitzender), Prof. Dr.-Ing. Harald Bolt, > Prof. Dr. Sebastian M. Schmidt > > ------------------------------------------------------------------------------------------------ > > ------------------------------------------------------------------------------------------------ > -- System Analyst Programmer PTI Lab Indiana University
