hostname 0-n (was Re: [jsdl-wg] Issues for todays phone conference)

[Andreas Savva]

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