Jeff would kill me if I spent time implementing this,
but what would be more awesome than condor_ssh_to_job would be for
the schedd to speak DNS, so you could have things like:
<cluster>.<proc>.<scheddname>.
condorjobs.cs.wisc.edu
mapped to IP addresses. Ideally, you'd give the startd several
IP addresses that it can map to slots, and as your job moves
around the DNS mapping is updated (obviously, short DNS TTLs)
Have the startd also fire up an sshd for the job. Have a tool
like condor_get_job_hostkey that gets the updated hostkey from
the schedd when the job starts running somewhere. At job submit
time, specify the public key(s) you'll want to be able to log in
with.
If the job is idle, map it back to the schedd*. Have the
schedd (and maybe the startd) listen on a port speaking HTTP to
cough up info about the job. Alternatively, just return host not
found when the job is idle.
The bummer about condor_ssh_to_job is that condor_ssh_to_job
is your ssh client - and if you have a real ssh client you want
to use, you're SOL.
Having a job to DNS mapping gets you a good part of the way
with Condor as a player in the IaaS world - you could run VM
Universe jobs and be able to find them again.
-Erik
*it might be kind of fun to able to ssh to a schedd and
interact with a simple shell.
_______________________________________________
HTCondor-devel mailing list
HTCondor-devel@xxxxxxxxxxx
https://lists.cs.wisc.edu/mailman/listinfo/htcondor-devel