From that perspective, I want a simple, practicable means of specifying both job submission requirements as well as available resource descriptions (where we all agree that "available" means "available to
Hi; While it is certainly interesting to explore multiple languages with different levels of expressiveness, the HPC profile work faces a challenge that I would argue is mostly focused on your first point around simplicity. This is because interoperability gets harder the more complicated the design and the working group also faces a time deadline of end-of-summer. So, whereas I very much encourage you and others to explore richer languages, the one I'm interested in (for the moment) is the first one. the requestor", not "raw availability"). I see two "base" cases for describing available resources: - Some simple ways of describing aggregates, such as the number of available compute nodes in a cluster or the overall "load" of a system (a number between 0" and 100%). - A simple way of describing the actual hardware/software resources available in a system so that clients like simple meta-schedulers can at least get at the raw data (with all the caveats about how much of the raw data to expose to any given requestor). This second type of description seems like it could be achieved with Donal Fellows' suggestion of an array of jsdl infosets. I fully recognize that these two base cases only cover some of the common scenarios that can occur in grids, but I would argue that they cover an important set and they are relatively easy to provide, implying that the HPC profile work could employ them without too much delay. Marvin. -----Original Message----- From: Michel Drescher [mailto:Michel.Drescher@uk.fujitsu.com] Sent: Friday, June 09, 2006 3:35 AM To: Karl Czajkowski Cc: Donal K. Fellows; Marvin Theimer; JSDL Working Group; ogsa-bes-wg@ggf.org; Ed Lassettre; Ming Xu (WINDOWS) Subject: Re: [ogsa-bes-wg] Re: [jsdl-wg] Questions and potential changes to JSDL, as seen from HPC Profile point-of-view Karl Czajkowski wrote:
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.
Yes! Yes! *waves the supporting flag*
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!
Hit base. After reading this mail, we are probably best fitted if we provide *two* resource models. Which may sound impractical, wasted resources or even impossible, I think the idea may be worth exploring: (Note that I take quite some assumptions for granted for the sake of simplicity:) While system administrators are interested in making the best use out of their machines (simple reason: return of investment), job submitters are interested in having their jobs actually executed rather than optimised 'til the last percent (while I acknowledge that there actually are submitters that do want to or even need to optimise that way, I think that this is a relatively small subset of Grid users at least in the future). A solution to this dilemma may be to provide two "languages", one fitting each group best: One language that job submitters use to specify resources they need, which sacrifices accuracy for practicability. This can be very simple, even name/value pairs. The other language, however, aims for maximum accuracy that I envision to be a feature rich, (strongly?) typed representation of their resources. Obviously, these two languages need matching when a job is submitted. The natural candidate for that is (Donal, forgive me for inaccuracy here) "something" coming from the RSS WG. Any boos, rotten eggs? Cheers, Michel -- Michel <dot> Drescher <at> uk <dot> fujitsu <dot> com Fujitsu Laboratories of Europe +44 20 8606 4834