For clarity, I should add that I was not intending to exclude any performance or dynamic availability indicators. I was merely trying to emphasize that what is needed is something predictive: the types of jobs that are acceptable, which ought to include "terms of service" parameters such as scheduling response time in a non-trivial QoS environment. This is not the same thing as an administrative overview, because the full resource set is meaningless without taking into account the operating policies (min/max job sizes and job durations) and the availability of the backing resources as influenced by the (site-specific) scheduling policy and load. And of course, this predictive data will exist in a continuum of precision, accuracy, and determinism. I don't want my statement below to be misconstrued as saying the user-level discovery is easy. On the contrary, it is MUCH more difficult than merely enumerating resources for an administrative user or "console" application. Oxana makes a point later on that I also would endorse. In the absence of good solutions to this problem, the administrative view is necessary to allow fallback. The status quo of our field is that users are "application administrators" who make all sorts of cunning decisions to coax the system into behaving more optimally than it ought to based on its own internal capabilities. I don't think one of these views can be addressed to the exclusion of the other. karl On Jun 09, Karl Czajkowski modulated:
One thing Donal mentioned which I would like to emphasize:
The discovery ought to be "what types of job are acceptable" and not what resources are there. Or rather, the latter is part of some administrative interface which is misleading for job-submitting users and middleware.
This may sound pedantic, but it will be crucial for interop. The discovery has to capture realistic operating policy, and not just give enticing catalogues of resources which can never be combined in a single request!
-- Karl Czajkowski karlcz@univa.com