A more accurate answer would be that "Globus has lots of different selectors", in that given the building blocks provided by MDS and GRAM, one can build many different strategies (as was our intention), and indeed people do just that . Thus, we see e.g.: * Policy-driven schedulers that use published information about site policies to determine where to send work (e.g., Dumitrescu). * Performance-driven schedulers that use information about past performance at different sites to determine where to send work. * Load-driven schedulers that use information about current load at different sites to determine where to send work. * Reservation-based schedulers that use advance reservations. (This only in research systems so far, due to lack of advance reservation support in most production deployments.) * Condor matchmaking * Alternative matchmaking strategies based on extended ClassAd-like systems * Schedulers that use information about data location to determine where to send work. * Coschedulers that use DUROC-like mechanisms to initiate computation only on sites that turn out to be available. I need to see more details on what is being proposed in terms of a selector interface, but I would be concerned if there was an attempt to incorporate this as a primitive. As the brief and far-from-comprehensive list above shows, there are many different resource selection strategies that may be applied, and these strategies may be applied in many different ways and in different places. Ian. At 06:37 PM 11/4/2005 +0900, Andreas Savva wrote:
- Other existing work on preferences or selection policy? - EGEE uses Condor classads (with EGEE extensions) - Globus (no, since no there is no scheduler)
_______________________________________________________________ Ian Foster www.mcs.anl.gov/~foster Math & Computer Science Div. Dept of Computer Science Argonne National Laboratory The University of Chicago Argonne, IL 60439, U.S.A. Chicago, IL 60637, U.S.A. Tel: 630 252 4619 Fax: 630 252 1997 Globus Alliance, www.globus.org