[Condor-users] possible bugs on Condor 6.7.2?

[Dan Christensen <jdc@xxxxxx>]

We're running Condor 6.7.2 on various Linux hosts, and I've noticed a
few minor issues.  I don't know if they are bugs, or intentional, or
an artifact of our configuration, so I thought I'd post them here.
The first two are being discussed in another thread...

1) When a vanilla universe job is evicted from a host (e.g. by
   condor_vacate), the output is not transferred back from that
   host, even though I have:

    should_transfer_files = YES
    when_to_transfer_output = ON_EXIT_OR_EVICT

  (By the way, the condor_vacate man page doesn't mention the word
  "evict", but I assume that this counts as eviction?  And the 
  index for the 6.7.2 manual only mentions the word "evict" once.)

2) [feature request] Would it be possible to have output of vanilla
   universe jobs transferred back to the submitting host periodically
   (controlled by a variable setting)?

3) If host A in the pool has a poorly configured firewall which
   disallows connections from host B, and if a job is submitted
   from host B which wants to run on host A, Condor spends a lot of
   time trying to connect to host A and having this time-out.  While
   this is happening, commands like "condor_q" and "condor_status"
   don't work on the submitting host---they just sit there waiting.
   Could the connection attempt happen in a separate thread, so
   the Condor daemons can still answer requests in the mean time?

3') [feature request] Is it possible to configure Condor to submit all
    jobs via the central manager, so execute nodes only need to allow
    connections from one predetermined host?

4) By default, Condor adds "Arch = <submit arch>" to each job's
   requirements line.  What's the best way to tell Condor that I
   don't care what architecture the execute host has?  I currently
   use "Arch =!= UNDEFINED" which is a bit of a hack.  Something
   like "Arch == ANY" would be nice;  or at least a documented
   way to do this using a trick like I use.  Same for OpSys.

Thanks,

Dan