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