[ogsa-bes-wg] Questions and potential changes to BES, as seen from HPC Profile point-of-view

[Christopher Smith]

Much like Donal, I don't see this requirement overmuch in our user base
(squarely in the "HPC Profile" space). Mostly users are submitting jobs that
can either utilize any architecture in their environment (the admins help
"make this so"), or they work within a homogeneous set (x86_64 running
Linux), so the JSDL document is good enough for a lot of these cases.
They'll also use queues and "host groups" to makes these kinds of selections
for them. Even the parallel jobs are almost always constrained such that all
tasks are running on a single architecture.

I realize that JSDL has some limitations in describing resources at this
time. I was also under the impression that some work was being done to
define some kind of information model based on generic name/value pairs
(where some names could be standardized by convention), but so that you
could represent any type of attribute. This would go along with some kind of
grammar to put stuff together into expressions that could be evaluated for
the purposes of resource requirement evaluation. I'm willing to live with
the JSDL v1.0 limitations, given that there will be some changes in the near
future if we work at it.

-- Chris


On 07/6/06 01:23, "Donal K. Fellows" <donal.k.fellows at manchester.ac.uk>
wrote:

> Peter Lane wrote:
>> Right, I meant something a little different when I mentioned JSDL.  JSDL
>> doesn't allow for describing complex requirements. For example,  one
>> might need a complex set of resources to run a distributed  application
>> on a cluster. The best JSDL can do, IIRC, is to allocate  N homogenous
>> resources. There's no way you can say, for example,  "give me two IA64
>> machines, two x86_64 machines, and two i386  machines". This is a very
>> real requirement by users of GRAM.
> 
> Hmm, that's not something I've ever seen in our job flows. On the other
> hand, we've found that our users aren't interested in specifying what
> sort of processor they use at all. They focus on the application instead
> and if that's part of the set described as supported by the container
> (ignoring questions of how this is discovered for the moment) then it
> hardly matters what the underlying CPU or OS is. (OK, both of those can
> certainly make a difference to the relevant performance metrics, but
> we'd rather state that we support a certain level of performance instead
> of providing some information that people can use to try to infer what
> they're really interested in.)
> 
> The only real use for matching on CPU and OS is if you're staging in the
> binary executable to run as part of the job. Physicists seem to like to
> do that; seems to be a peculiarity of that community. We don't see the
> same thing to anything like as great an extent among other scientists
> and engineers (and we have very little CS in our usage profile, though
> if we did I'd expect them to be similar to the physicists). On the other
> hand, the physicists seem to prefer to buy their own clusters too.
> 
> Oh, you're supporting physicists? :-)
> 
> Donal.
>