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