Mailing List Archives
Authenticated access
|
|
|
[Date Prev][Date Next][Thread Prev][Thread Next][Date Index][Thread Index]
Re: [Condor-users] Is this a feature or a bug in Condor 6.7.19?
- Date: Tue, 11 Jul 2006 22:44:23 -0400
- From: Gabriel Mateescu <gabriel.mateescu@xxxxxx>
- Subject: Re: [Condor-users] Is this a feature or a bug in Condor 6.7.19?
Hi Dan,
I sent a report to condor-admin and I received
the ticket number #13987.
Regarding the path specification, I realize
that there is a mismatch between Globus and
Condor:
(1) In Condor, the path, e.g., Output, refers
to the local (submission) side;
)2) In Globus, the path, e.g., stdout, refers to
the remote (execution) side.
Now the problem with the recent change in Condor
of the way the Output job attribute of grid-universe
jobs is translated is as follows:
1. Assume in the GT 4 job spec, submitted, say
with globusrun-ws, I have
<stdout>file.out</stdout>
2. GRAM converts this to the full path
stdout = $GLOBUS_USER_HOME/file.out
3. Assume the job received by GRAM is passed to
Condor-G (meta-scheduling). Condor-G generates
another GT 4 RSL which contains
<directory>${GLOBUS_SCRATCH_DIR}/job_HASH/</directory>
<stdout>${GLOBUS_SCRATCH_DIR}/job_HASH/file.out</stdout>
<fileStageOut>
<sourceUrl>$GLOBUS_USER_HOME/file.out </sourceUrl>
...
</fileStageOut>
4. So <stdout> matches the job directory (which is good)
but it does not match the <sourceUrl>, i.e., the
job's output will go to <stdout> but, when the remote
job is done, Condor-G will try to stage out <sourceUrl>
which is an empty file.
5. The workaround for situation 3; 4 is to have in the
Condor-G job description simply a file name
Output = file.out
in which case Condor-G will generate a GT 4 RSL
containing
<directory>${GLOBUS_SCRATCH_DIR}/job_HASH/</directory>
<stdout>${GLOBUS_SCRATCH_DIR}/job_HASH/file.out</stdout>
<fileStageOut>
<sourceUrl>${GLOBUS_SCRATCH_DIR}/job_HASH/file.out</sourceUrl>
...
</fileStageOut>
so <sourceUrl> matches <stdout> and stage-out works.
But if we are doing meta-scheduling, Output at step 2
comes from the GRAM-generated stdout attribute,
which is a full path, so with the current behavior
of Condor-G the only workaround I see is to hack the
Globus-Condor adapter condor.pm to convert the
full path for stdout set by GRAM to a relative path,
but this seems to be a big hack.
Gabriel
On Tue, 2006-07-11 at 20:25, Dan Bradley wrote:
> Gabriel,
>
> There was an intentional change to the behavior of grid-universe jobs
> having paths specified for the output files, in order to make it
> consistent with non-grid universe jobs, where the path specifies a path
> on the submit side rather than the execute side. The developer who is
> most knowledgeable about that is on vacation at the moment, so I do not
> know if there is a way to translate what you are trying to do (using a
> path to a file on the remote site) into the revised syntax.
>
> I recommend sending this report to condor-admin@xxxxxxxxxxx so that we
> do not lose track of it.
>
> Thanks,
> --Dan
>
> On Jul 11, 2006, at 4:54 PM, Gabriel Mateescu wrote:
>
> > Hello,
> >
> > I noticed that the mapping of the
> > job's stdout has changed from
> > Condor 6.7.17 to 6.7.19 in an
> > important way.
> >
> >
> >
> > 1. "Old" (6.7.17) mapping for Condor-G jobs for GT4
> > resources:
> >
> > the job attribute
> >
> > Out = /path/to/file
> >
> > was mapped to
> >
> > <stdout>${GLOBUS_SCRATCH_DIR}/job_HASH/file</stdout>
> >
> > <fileStageOut>
> > ...
> > <sourceUrl>
> > file:///${GLOBUS_SCRATCH_DIR}/job_HASH/file
> > </sourceUrl>
> > ...
> > </fileStageOut>
> >
> > where ${GLOBUS_SCRATCH_DIR}/job_HASH is also the value
> > of the <directory> element.
> >
> >
> >
> >
> > 2. "New" (Condor 6.7.19) mapping for Condor-G jobs for GT4
> > resource:
> >
> > The job attribute
> >
> > Out = /path/to/file
> >
> > is mapped to
> >
> > <stdout>${GLOBUS_SCRATCH_DIR}/job_HASH/file</stdout>
> >
> > <fileStageOut>
> > ...
> > <sourceUrl>
> > file:///path/to/file
> > </sourceUrl>
> > ...
> > </fileStageOut>
> >
> >
> > This new behavior seems to me less suitable than
> > the old behavior, because now the <sourceUrl> path
> > does not match <stdout>, which is still mapped to
> > ${GLOBUS_SCRATCH_DIR}/job_HASH, and thus one
> > cannot use absolute paths in the Out specification
> > any more; in other words, the staged out file
> > will be an empty file rather than stdout.
> >
> >
> > But what I do not know is if the new behavior has
> > been done intentionally or if it is a bug.
> >
> > Thank you.
> > Gabriel
> >
> >