Return-Path: X-Original-To: apmail-airavata-dev-archive@www.apache.org Delivered-To: apmail-airavata-dev-archive@www.apache.org Received: from mail.apache.org (hermes.apache.org [140.211.11.3]) by minotaur.apache.org (Postfix) with SMTP id 1825910F19 for ; Mon, 13 Jan 2014 19:45:20 +0000 (UTC) Received: (qmail 49423 invoked by uid 500); 13 Jan 2014 18:33:44 -0000 Delivered-To: apmail-airavata-dev-archive@airavata.apache.org Received: (qmail 47310 invoked by uid 500); 13 Jan 2014 18:31:52 -0000 Mailing-List: contact dev-help@airavata.apache.org; run by ezmlm Precedence: bulk List-Help: List-Unsubscribe: List-Post: List-Id: Reply-To: dev@airavata.apache.org Delivered-To: mailing list dev@airavata.apache.org Received: (qmail 41401 invoked by uid 99); 13 Jan 2014 18:21:44 -0000 Received: from nike.apache.org (HELO nike.apache.org) (192.87.106.230) by apache.org (qpsmtpd/0.29) with ESMTP; Mon, 13 Jan 2014 18:21:44 +0000 X-ASF-Spam-Status: No, hits=1.5 required=5.0 tests=HTML_MESSAGE,RCVD_IN_DNSWL_LOW,SPF_PASS X-Spam-Check-By: apache.org Received-SPF: pass (nike.apache.org: domain of glahiru@gmail.com designates 209.85.212.174 as permitted sender) Received: from [209.85.212.174] (HELO mail-wi0-f174.google.com) (209.85.212.174) by apache.org (qpsmtpd/0.29) with ESMTP; Mon, 13 Jan 2014 18:21:37 +0000 Received: by mail-wi0-f174.google.com with SMTP id g10so1548623wiw.7 for ; Mon, 13 Jan 2014 10:21:17 -0800 (PST) DKIM-Signature: v=1; a=rsa-sha256; c=relaxed/relaxed; d=gmail.com; s=20120113; h=mime-version:in-reply-to:references:date:message-id:subject:from:to :content-type; bh=5keJN2zrYfH6lOL+4vkgm8+5r47B8BhHoD7taWi7hRM=; b=AeW3WQiOcZdf1K9LQ2Cvp0sFY3mgdWzKV+rn5dGSTzJ1Q5N2IAfye/jvbzPSJI+/Yp IJbPJp/Z4MvJBjfmmYrkFV9CnuausxeP0m0Zuf8FMtRcGuIPDBtGhvO6/Mkd+D00aYM6 w7+qcD4tU5i+nt0TeMG5u3+3biNP65KdItrqqqRj4BmIbhSexP9gI9AS5LU7BP2gspGX yTct2/4V8YyP6uDPh/wvIHxbRoJEDjnr/urE4U9JntgtDj8Sand6O0NQ1JS3RJKq72HJ V1mbFwvFCZ3wRp20gLqs0+NuA0SpwGdeN+wimuBZlManEE5Fnhodjmu7AASjVseQrNTf OmPQ== MIME-Version: 1.0 X-Received: by 10.180.12.146 with SMTP id y18mr16958295wib.37.1389637277276; Mon, 13 Jan 2014 10:21:17 -0800 (PST) Received: by 10.217.59.195 with HTTP; Mon, 13 Jan 2014 10:21:17 -0800 (PST) In-Reply-To: <98D718CF-FAC7-46EE-BBA3-BBDAACC85F2D@apache.org> References: <98D718CF-FAC7-46EE-BBA3-BBDAACC85F2D@apache.org> Date: Mon, 13 Jan 2014 13:21:17 -0500 Message-ID: Subject: Re: Predefined parent working directory for jobs From: Lahiru Gunathilake To: dev Content-Type: multipart/alternative; boundary=001a11c2ae3247620304efde2436 X-Virus-Checked: Checked by ClamAV on apache.org --001a11c2ae3247620304efde2436 Content-Type: text/plain; charset=windows-1252 Content-Transfer-Encoding: quoted-printable Hi Suresh, Yes Suresh you are correct but I was under the impression that we need to enforce this thing in server side to avoid application description creation error etc. Each server have multiple application descriptors which are highly coupled with each host, so scratch working directories for each host has to configure manually (we don't re use them, have to create one for each host)= . Regards Lahiru On Mon, Jan 13, 2014 at 11:14 AM, Suresh Marru wrote: > Saminda, Lahiru, > > Why not use the staticWorkingDirectory option within Application > Deployment Description [1]? The intention of this option was, within the > provider, if this is provided, it ignores the scratchWorkingDirectory and > always uses a static working directory location. > > Also, if I re-read Saminda=92s original request, is it not the normal GFa= c > behavior? I mean, within the specified directory > scratchWorkingDirectory=3Dfoo on host A and scratchWorkingDirectory=3Dbar= on > hostB, all new sub-directories will be created. What is the precise > difference from this behaviour? > > Suresh > > [1] - > https://svn.apache.org/repos/asf/airavata/trunk/modules/commons/gfac-sche= ma/src/main/resources/schemas/ApplicationDeploymentDescription.xsd > > On Jan 13, 2014, at 9:53 AM, Lahiru Gunathilake wrote= : > > > Hi Saminda, > > > > You can do this easily by writing another Handler and make sure you cal= l > this handler after AppDescriptorCheckHandler. You can have properties in > your handler configuration and read those properties and configure > different hosts with different base directory locations. So your handler > configuration could looks like this. > > > > > > AppDescriptorCheckHandler"/> > > class=3D"org.apache.airavata.gfac.handler.BaseDirectorySetupHandler"> > > value=3D"/home/trestles/base-directory"/> > > > > > > > > With handler properties you do not have to hard-code the host specific > directories or create another configuration file. > > > > Hope this helps ! > > > > Regards > > Lahiru > > > > > > On Fri, Jan 10, 2014 at 3:35 PM, Saminda Wijeratne > wrote: > > A specific gateway will have access to the directory location "foo" in = a > certain remote host A. Therefore the gateway would like to have all the > working directories for the jobs running in remote host A to be located > inside "foo". Similarly for jobs running in remote host B, all the workin= g > directories should be created inside the directory location "bar" of whic= h > the gateway has access. > > > > The reason why the working directories needs to be located in locations > accessible to the gateways is because the gateway may perform manual data > transfer. > > > > Thanks, > > Saminda > > > > On Fri, Jan 10, 2014 at 2:04 PM, Raminder Singh < > raminderjsingh@gmail.com> wrote: > > Hi Saminda, > > > > Do you want all the jobs should use same working directory? > AppDescriptorCheckHandler in GFAC handles working directory, input-output > directory in GFAC. You can control these configuration by customizing thi= s > input handler. Please describe the use case and i will be able to provide > better input. > > > > Thanks > > Raminder > > > > On Jan 10, 2014, at 1:14 PM, Saminda Wijeratne > wrote: > > > >> Hi Devs, > >> > >> I want the parent directory of each working directory of the jobs to b= e > a predefined path defined for each remote host. What is the easiest way t= o > do this? > >> > >> Thanks, > >> Saminda > > > > > > > > > > > > -- > > System Analyst Programmer > > PTI Lab > > Indiana University > > --=20 System Analyst Programmer PTI Lab Indiana University --001a11c2ae3247620304efde2436 Content-Type: text/html; charset=windows-1252 Content-Transfer-Encoding: quoted-printable
Hi Suresh,

Yes Suresh you are correct b= ut I was under the impression that we need to enforce this thing in server = side to avoid application description creation error etc.
Each se= rver have multiple application descriptors which are highly coupled with ea= ch host, so scratch working directories for each host has to configure manu= ally (we don't re use them, have to create one for each host).

Regards
Lahiru


On Mon, Jan 13, 2014 at 11:14 AM= , Suresh Marru <smarru@apache.org> wrote:
Saminda, Lahiru,

Why not use the staticWorkingDirectory option within Application Deployment= Description [1]? The intention of this option was, within the provider, if= this is provided, it ignores the scratchWorkingDirectory and always uses a= static working directory location.

Also, if I re-read Saminda=92s original request, is it not the normal GFac = behavior? I mean, within the specified directory scratchWorkingDirectory=3D= foo on host A and scratchWorkingDirectory=3Dbar on hostB, all new sub-direc= tories will be created. What is the precise difference from this behaviour?=

Suresh

[1] - https://svn.apache.org/repos/asf/airavata/trunk/m= odules/commons/gfac-schema/src/main/resources/schemas/ApplicationDeployment= Description.xsd

On Jan 13, 2014, at 9:53 AM, Lahiru Gunathilake <glahiru@gmail.com> wrote:

> Hi Saminda,
>
> You can do this easily by writing another Handler and make sure you ca= ll this handler after AppDescriptorCheckHandler. =A0You can have properties= in your handler configuration and read those properties and configure diff= erent hosts with different =A0base directory locations. So your handler con= figuration could looks like this.
>
> <InHandlers>
> =A0 =A0 =A0 =A0 =A0 =A0 <Handler class=3D"org.apache.airavata.= gfac.handler. AppDescriptorCheckHandler"/>
> =A0 =A0 =A0 =A0 =A0 =A0 <Handler class=3D"org.apache.airavata.= gfac.handler.BaseDirectorySetupHandler">
> =A0 =A0 =A0 =A0 =A0 =A0 =A0 =A0 =A0 =A0 <property name=3D"tres= tles" value=3D"/home/trestles/base-directory"/>
> =A0 =A0 =A0 =A0 =A0 =A0 </Handler>
>
> =A0 =A0 =A0 =A0 </InHandlers>
> With handler properties you do not have to hard-code the host specific= directories or create another configuration file.
>
> Hope this helps !
>
> Regards
> Lahiru
>
>
> On Fri, Jan 10, 2014 at 3:35 PM, Saminda Wijeratne <samindaw@gmail.com> wrote:
> A specific gateway will have access to the directory location "fo= o" in a certain remote host A. Therefore the gateway would like to hav= e all the working directories for the jobs running in remote host A to be l= ocated inside "foo". Similarly for jobs running in remote host B,= all the working directories should be created inside the directory locatio= n "bar" of which the gateway has access.
>
> The reason why the working directories needs to be located in location= s accessible to the gateways is because the gateway may perform manual data= transfer.
>
> Thanks,
> Saminda
>
> On Fri, Jan 10, 2014 at 2:04 PM, Raminder Singh <raminderjsingh@gmail.com> wrote:
> Hi Saminda,
>
> Do you want all the jobs should use same working directory? AppDescrip= torCheckHandler in GFAC handles working directory, input-output directory i= n GFAC. You can control these configuration by customizing this input handl= er. Please describe the use case and i will be able to provide better input= .
>
> Thanks
> Raminder
>
> On Jan 10, 2014, at 1:14 PM, Saminda Wijeratne <samindaw@gmail.com> wrote:
>
>> Hi Devs,
>>
>> I want the parent directory of each working directory of the jobs = to be a predefined path defined for each remote host. What is the easiest w= ay to do this?
>>
>> Thanks,
>> Saminda
>
>
>
>
>
> --
> System Analyst Programmer
> PTI Lab
> Indiana University




--
= System Analyst Programmer
PTI Lab
Indiana University
--001a11c2ae3247620304efde2436--