See section 3.2.10 for a complete description of Condor's dynamic deployment tools.
Condor's dynamic deployment tools (condor_cold_start and condor_glidein) allow new pools of resources to be incorporated on the fly. While Condor is able to manage compute jobs remotely through Globus and other grid-computing protocols, dynamic deployment of Condor makes it possible to go one step further. Condor remotely installs and runs portions of itself. This process of Condor gliding in to inhabit computing resources on demand leverages the lowest common denominator of grid middleware systems, simple program execution, to bind together resources in a heterogeneous computing grid, with different management policies and different job execution methods, into a full-fledged Condor system.
The mobility of Condor services also benefits from the development of Condor-C, which provides a richer tool set for interlinking Condor-managed computers. Condor-C is a protocol that allows one Condor scheduler to delegate jobs to another Condor scheduler. The second scheduler could be at a remote site and/or an entry point into a restricted network. Delegating details of managing a job achieves greater flexibility with respect to network architecture, as well as fault tolerance and scalability. In the context of glide in deployments, the beach-head for each compute site is a dynamically deployed Condor scheduler which then serves as a target for Condor-C traffic.
In general, the mobility of the Condor scheduler and job execution agents, and the flexibility in how these are interconnected provide a uniform and feature-rich platform that can expand onto diverse resources and environments when the user requires it.