hostname 0-n (was Re: [jsdl-wg] Issues for todays phone conference)
Andreas Savva
andreas.savva at jp.fujitsu.com
Tue Apr 19 00:24:15 CDT 2005
My concern here isn't so much that enumerating a set of hostnames and
choosing N of them isn't useful. It is rather that this is a case of an
implicit choice rule different from our default "satisfy all" rule.
In giving the example below, I was trying to suggest that we did support
part of the use case and could perhaps claim that the rest can be
satisfied when composing jsdl with some other operator language.
If the consensus is that having a small number of instances of this rule
(I can think of another place where we have a variant) is a good thing
then I might go along with it. But I feel it is clearer (though perhaps
inconvenient) not to have such exceptions.
Let's chat about this tonight (over Champagne as Ali suggested :-)
Andreas
Karl Czajkowski wrote:
> On Apr 14, Andreas Savva loaded a tape reading:
>
>>I have a followup question on changing the hostname from 0-1 to 0-n. In
>>the spec we had said that hostname may refer to a single host or any
>>logical group of hosts. (And that logical group could be anything
>>understood by the system.) The intention was to be able to do something
>>like
>><Resource>
>> <HostName> the-nine-muses </HostName>
>> ...
>> <ResourceCount> <exact>2.0<exact></ResourceCount>
>></Resource>
>>
>>And get back, for example, resources "thalia" and "urania".
>>
>>Doesn't this cover already (most of) the use case mentioned below and is
>>there really a need to change the multiplicity of this element.
>>
>>Andreas
>>
>
>
>
> A common real-world example is that I am choosing from a set of nodes
> in a cluster according to an arbitrary application-specific constraint
> that cannot be captured in the resource selection language otherwise.
>
> I've seen this with some stateful "storage" clusters where one job
> wrote data to a set of nodes and subsequent jobs need to process them.
> It is ugly but useful. In GRAM we have seen sites add site-specific
> extensions to handle this since we did not provide it in our RSL.
>
> karl
>
--
Andreas Savva
Fujitsu Laboratories Ltd
More information about the jsdl-wg
mailing list