[Condor-devel] [wright@xxxxxxxxxxx: how file transfer works (attn: karen and condor-week presenters)]

[Erik Paulson <epaulson@xxxxxxxxxxx>]

This is 8 years old, so obviously, things may have changed. 

(I'm also curious if the "old syntax" still works. Condor isn't
very good at actually deprecating features ;)

-Erik

----- Forwarded message from Derek Wright <wright@xxxxxxxxxxx> -----

Date: Fri, 25 Apr 2003 23:02:27 -0500
To: condor-team@xxxxxxxxxxx
From: Derek Wright <wright@xxxxxxxxxxx>
Sender: owner-condor-team@xxxxxxxxxxx
Subject: how file transfer works (attn: karen and condor-week presenters) 


ok, everyone, i'm done checking in my changes to the file transfer
stuff.  here's the detailed explaination of how it all works.  the old
syntax and attributes are still around for backwards compatibility,
but they don't provide the cool new IF_NEEDED functionality, and
should be deprecated.  we should encourage new users to use the new
attribute names (since they're less confusing, hopefully), and change
the docs to just explain how the new ones work (with a little note
about the old ones being deprecated).

also, for any condor-week slides that talk about file transfer, it'd
be nice to see the new syntax...

here goes...


----------------------------------------
first, a little background
----------------------------------------

the only change is to TransferFiles (or transfer_files in the submit
file).  this used to have 3 possible options: "NEVER", "ONEXIT", or
"ALWAYS".  while "NEVER" was pretty clear, ONEXIT vs. ALWAYS was
usually a source of confusion.  moreoever, it combined two things into
a single attribute: whether or not you wanted to transfer the files,
and when you wanted the output transfered back.  so, by specifying
when you wanted the output back (ALWAYS vs. ONEXIT), you implicity
also specified that you wanted the file transfer to happen in the
first place.  there was no good way to graft IF_NEEDED into this
attribute, and since i had to introduce a new attribute to get it to
work, i decided to reorganize things to make them more clear...


----------------------------------------
how it now works:
----------------------------------------

the TransferFiles attribute has been split up, and the two things it
controls are independent knobs.  to decide if and when you want to
transfer files in the first place, you now specify:

ShouldTransferFiles = YES | NO | IF_NEEDED

("should_transfer_files" also works for consistency with the other
submit file syntax).

"NO" means never (in fact, submit recognizes "never" and treats it as
NO).  "IF_NEEDED" means we only want to do file transfer if we're
matched with a machine in a different FileSystemDomain from the one
the submit machine is in.  if we're in the same fs domain, IF_NEEDED
becomes NO.  "YES" means we always want to transfer, even if we're in
the same fs domain.


the second knob determines when to transfer the output back to the
submit machine:

WhenToTransferOutput = ON_EXIT | ON_EXIT_OR_EVICT

("when_to_transfer_output" also works, for consistency).  this option
only makes sense and is only defined if should_transfer_files is
either YES or IF_NEEDED.  if you define should_traster_files = NO and
provide a value for when_to_transfer_output, condor_submit exits with
a fatal error asking you to remove this contradition from your submit
file.  

as you can see, "ALWAYS" is no longer an option, since that's just
confusing.  ON_EXIT is what most people want: only transfer back the
output when the job exits on its own.  in this case "exit" also
includes dying with a seg fault, exiting with a non-zero status, etc.
basically, any time a starter notices the job exits when the starter
didn't explicitly tell it to get off.  ON_EXIT_OR_EVICT means to
transfer the files back any time a job leaves a given execution site,
whether it exited on its own, or if it was evicted by the starter and
hasn't completed yet.

"when_to_transfer_output = ON_EXIT_OR_EVICT" is identical in behavior
to what "transfer_files = ALWAYS" used to mean.  however, since it's
the weird special case, alain and i decided it was better to make the
name somewhat more complicated sounding, to discourage people from
using it, thinking that was the better choice. :) plus, the more
verbose name makes it more clear what the difference is between it and
the regular ON_EXIT option.


----------------------------------------
the default behavior
----------------------------------------

on windoze, the defaults for these are:

should_transfer_files = yes
when_to_transfer_output = on_exit

this is the same behavior we've always had, since the old default was
for "transfer_files = onexit", and these settings are equivalent to
that.  (by the way, yes, it's all case insensitive).


on unix, the default is:

should_transfer_files = no

however, if the user specifies any file transfer related attributes at
all (should_transfer_files, transfer_input_files, etc), they *MUST*
also define when_to_transfer_output, since it's important that they
tell condor the bahavior they want.  this is how it's always worked,
condor_submit just now prints out error messages referring to the new
attributes the user should define.


----------------------------------------
backwards compatibility
----------------------------------------

the old "transfer_files" syntax is still recognized by condor_submit,
it just maps into the following combinations:

                      possible values of FileTransfer 
                      NEVER          ONEXIT    ALWAYS
----------------------------------------------------------------
ShouldTransferFiles    NO            YES       YES
WhenToTransferOutput   <UNDEFINED>   ON_EXIT   ON_EXIT_OR_EVICT


also, in case the execute machine is a pre 6.5.2 version of the
condor_starter, condor_submit always includes an equivalent value for
TransferFiles in the job ad it creates, even if the user is specifying
the new attributes in the submit file.  for this conversion,
ShouldTransferFiles = IF_NEEDED is just treated as YES, since that's
the best we can do.  otherwise, WhenToTransferOutput is just encoded
into TransferFiles given the mapping shown above.  the 6.5.2 starter
always looks in the job ads for the new attributes, and if it finds
those, it ignores TransferFiles.  however, if the new starter doesn't
see the new attributes, it checks the old attribute and does what that
says.  


this is probably more verbose than we need in the manual, but i
thought i'd motivate the changes while i was at it.  please let me
know if anyone has any questions or concerns.  thanks!

-d



----- End forwarded message -----