Mailing-List: contact dev-help@oodt.apache.org; run by ezmlm
Precedence: bulk
Reply-To: dev@oodt.apache.org
Received-SPF: pass (athena.apache.org: domain of sheryljj@gmail.com designates
 209.85.213.171 as permitted sender)
MIME-Version: 1.0
In-Reply-To: <73fcda08-1f6c-4d80-9b0f-dcb640c067ec@me.com>
References: <73fcda08-1f6c-4d80-9b0f-dcb640c067ec@me.com>
Date: Tue, 1 May 2012 21:49:52 -0700
Message-ID: 
 <CAN=EhLvPY6fJHwhp_AL4za3q-y6muWCRGVL_v5O1oPU4zTCsgw@mail.gmail.com>
Subject: Re: Staging CAS-PGE config file...
From: Sheryl John <sheryljj@gmail.com>
To: dev@oodt.apache.org
Content-Type: multipart/alternative; boundary=14dae9340a5b01973804bf066b7e

--14dae9340a5b01973804bf066b7e
Content-Type: text/plain; charset=ISO-8859-1

Hi Brian,

I'm still going through the wmgr -2 & wengine branch CAS-PGE, but are you
suggesting to always use resource manager to support the configuration?

Actually, we've not yet used resource manager with workflow and CAS-PGE in
the VPICU project (currently in the process of learning and setting it up )
and, so I have little knowledge of how the resource manager can support
this. But if it does support, does that imply that I have to use PGEs and
workflows with resource mgr?

I agree that setting the *ConfigFilePath* to the temporary dir where the
task executes on, within the config itself to generate the object is kind
of confusing and should be given before it runs.

On Tue, May 1, 2012 at 5:20 PM, Brian Foster <holenoter@mac.com> wrote:

> hey guys,
>
> in the wengine branched CAS-PGE, it supported staging the CAS-PGE's XML
> config file to tmp directory so it could be parsed and then processed and
> then the staged config file was copied CAS-PGE's working directory (had to
> be copied later since the working directory information is in the config
> file).  I think this should be something the resource manager should
> instead support... staging job binaries and config that is need to run the
> jobs would be a cleaner implementation than what wengine CAS-PGE does...
> CAS-PGE would still stage Products and ingest them itself (that is a
> CAS-PGE specified task), however the knowledge of getting CAS-PGE's
> configuration file which configures it should already be there when it
> runs... otherwise you kinda need configuration for CAS-PGE configuration
> (chicken and egg problem)... what you guys think?
>
> -brian
>


-- 
-Sheryl

--14dae9340a5b01973804bf066b7e--