[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?



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
> >
> >