[glue-wg] GLUE 2.0 Specification - draft 41 - Working GroupLastCall

[Burke, S (Stephen)]

>   That's it for computing, storage to follow ...

OK ... on the diagram I again have doubts about the multiplicities:
Share to Resource says 1..* at both ends but I think they should both be
*. Conversely, Service to AccessProtocol says * but I'm inclined to
think it should be 1..*, an SE with no way to access the data wouldn't
be very useful ...

  As a general comment, the text uses the word "capacity" (or
"capacities") in many places to mean something like "the ability to
store data". I think this is a bad choice of word, partly because of
possible confusion with the Capacity objects and partly because I don't
think it's really the right word anyway. Also in some places the text
uses "storage extent" to mean what seems to be something similar, and
again I don't think "extent" is a very good word. However, I'm not
entirely sure what to recommend as an alternative - perhaps
"capability"?

  Service: four of the association descriptions use the word "offers",
which I suspect isn't really the right word for most of them - for
protocols it's OK, and maybe for Shares, but it doesn't really offer
managers (they aren't externally visible) and it definitely doesn't
offer Capacities, it just has them.

  SSCapacity: Here the word "capacity" appears in the description, so it
seems that a Capacity object tells you the capacity of a capacity ...
not very good! I think the *Size attributes need a more complete
description, as this always seems to confuse people. Indeed there is no
general explanatory text for this object and I think there should be
some, e.g. to say that this is a whole-SE summary of the more detailed
Share-level information.

  AP: The association to the SS2CS object (as shown in the diagram) is
missing from the table. Again there is no explanatory text.

  Endpoint: are we expecting access protocol endpoints (e.g. for a
classic SE) to be published as Endpoints or StorageEndpoints? There is
no text to indicate what the endpoint is expected to be.

  Share: the Path is marked as mandatory - maybe that's OK and you
should publish "/" if there is no specific path, but if so I think it
should say so explicitly. Indeed it needs to be clearer exactly what the
semantics are here - this is a SURL prefix to be used when files are
written, and cannot in general be reverse-engineered, i.e. given a SURL
you can't reliably deduce which Share it's in. Tag: I think we need a
better description here, something which would correspond to the space
token description for an SRM while being generic enough to be applicable
to other technologies. In the associations, Endpoint and Resource are
marked as mandatory when the objects are optional (and MappingPolicy is
missing because it's missing from the main entities too). I think the
text description for Share is not very clear.

  ShareCapacity: the description says "size and state" but in fact it's
only the size. Again I think the attributes need a clearer description.
The text below the table could also be clearer, at least my mental
parser is currently throwing an error :)

  Manager: Type seems a slightly strange name for the attribute, things
like "enstore" and "castor" aren't really types. Actually this applies
to ComuptingManager too although I didn't pick it up there, are "lsf"
and "pbs" types? Also since both CM and SM have a Type attribute should
it anyway be defined in the parent Manager entity? (ditto Version). For
the StorageResource association it says 1..* for the multiplicity but
the text says "zero or more" - I think the text is right. There is no
explanatory text below the table, I think there should be some.

  StorageResource: as you might guess I'm still inclined to prefer
DataStore! Since we have ExecutionEnvironment and not ComputingResource
this is evidently not a hard naming rule ... the description says "one
or more endpoints/shares", it should be "zero or more". The Latency
description is wrong, in this case it's the actual latency and not the
maximum (tape is Nearline here even if it's part of a D1T1 Share). The
Manager and Share associations say that they are mandatory, but I think
the reality is a bit more complicated - you must have at least one of
them otherwise the object will be completely detached, but logically
either one of them could be missing - although possibly that would make
a mess of the renderings. There is no explanatory text, this definitely
needs some given all the trouble it causes ...

  SS2CS: The AccessProtocol relation is marked as multiplicity 1, but I
think it should be *. One one side you could have a "close SE" relation
involving several protocols (e.g. rfio and file). On the other side you
may want to have the network info regardless of protocol (e.g. for
gridftp). Again there is no general explanatory text for this object.

  That's everything for storage - there will be one more mail about the
type definitions, when I find the energy to write it!

Stephen