Re: [Condor-users] Using condor to update condor

[Matt Hope <matthew.hope@xxxxxxxxx>]

On 6/24/05, Ian Chesal <ICHESAL@xxxxxxxxxx> wrote:
> This is more for Windows installations, where shared binaries are
> impossible to deploy (or are they?). It would be pretty cool if there
> was a way, say from the central machine (for security of course), to
> push out new condor binaries to all the machines in the system using
> Condor itself to do the job. I can't see running this as a regular job
> since the jobs likely won't have the permissions required to overwrite
> existing binaries. There would need to be a way for Condor itself to
> grab and install the binaries as SYSTEM (or root, but since Unix/Linux
> installs can used shared FS for the binaries this feature seems less
> useful).
> 
> A command akin to the condor_reconfig -all -- only it'd be
> condor_redeploy -all.
> 
> Anyone out there trying something like this?

There are inumerable commercial solutions to the problem of deploying
executables (or anything else for that matter) to windows machines.

The issue you have is that this should happen only if the daemon is
not in use (terminating a schedd that is running jobs is prob not a
nice plan)

Therefore unless you are willing to take this (uncommon admittedly)
hit you need a mechnism for determining when this is appropriate on a
machine by machine basis...

One means of ensuring that the machine eventually becomes free for
upgrade is to reconfig the START expression. for schedd's I can't
think of a simple (start no more shadows" but don't kill running ones"
expression of the top of my head but steadily reducing the max jobs
running to the number of active shadows would do the trick (if
cumbersomely)

The alternate is just sit and wait till condor_q -run says nothing is
running...not guaranteed to ever be true though.

Most of my windows admin friends swear by active directory (if you can
afford it and the time to learn it) for pushing out machine setups but
this may well be overkill/overpriced for you

Matt