[Date Prev][Date Next][Thread Prev][Thread Next][Date Index][Thread Index]
Re: [Condor-devel] [wright@xxxxxxxxxxx: how file transfer works (attn: karen and condor-week presenters)]
He hit on it a bit - I think the weirdness comes from moving between
slots that have a shared filesystem and that don't. It may not be
possible for the starter to figure out what files it should move.
It's been a long time since I've thought about this, but that's what's
going off in my head this morning.
-Erik
On Thu, Jun 30, 2011 at 10:49:54AM -0400, Matthew Farrellee wrote:
> Thanks for the history. It's so close! It just misses why Derek outlawed
> IF_NEEDED+ON_EXIT_OR_EVICT.
>
> I've added defaults of IF_NEEDED+ON_EXIT for 7.7, see #2273. Doing so
> has uncovered a few bugs in the test suite and what may be a bug with
> IF_NEEDED and remaps when IF_NEEDED -> NO. In the process, I removed
> TransferFiles from condor_submit's language. There are currently a few
> islands of related code that can be garbage collected independently.
>
> Best,
>
>
> matt
>
> On 06/30/2011 10:30 AM, Erik Paulson wrote:
> >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 -----
> >_______________________________________________
> >Condor-devel mailing list
> >Condor-devel@xxxxxxxxxxx
> >https://lists.cs.wisc.edu/mailman/listinfo/condor-devel
