[glue-wg] New version of GLUE 2.1 draft

[Paul Millar]

Hi Salvatore,

Some comments:

GPUs:

PhysicalGPUs

     "The number of physical GPUs in one ExecutionEnvironment
     instance, i.e. the number of video cards per Worker Node."

The description isn't great.  My rule-of-thumb is to cross out 
information that is in the Attribute name and the Entity name.  This leaves:

     "The number of [--] in one [--] instance, i.e. the number
     of video cards per Worker Node."

The second part ("the number of video cards per Worker Node") is an 
example, rather than a definitive statement.

My guess is that PhysicalGPUs should be described something like:

     "The theoretical maximum number of independent SIMD
     co-processors that any one job may access.  Note that
     site policies may further limit the number of available
     SIMD co-processes."

I'm also not sure why PhysicalGPUs would be useful, but GPGPU isn't 
really my thing.

The LogicalGPUs has similar problems: the description doesn't contain 
much information and uses "i.e." when what follows is an example. Here's 
a possible alternative.

     "The number of independent SIMD co-processors that a job
     may access."

For GPUVendor, GPUModel and GPUModel I suggest setting up a registry of 
known values.  Having a "free format" text is a recipe for breaking 
interoperability --- at the very least, it forces users to profile GLUE.

One obvious omission is the API.  If my executable uses some particular 
API (CUDA, for example), how do I know it will work?


SLAs

GLUE provides reader-agnostic information: two people/agents can read 
the same GLUE information and deduce information correctly.  If there 
are any user-specific information then it is expressed as UserDomain in 
an object linked from a UserDomain (such as the Policy entities).

An SLA is a legally binding agreement between a service provider and the 
consumer(s).  A service provider can provide different SLAs to different 
individuals, making SLA information user-specific.  Therefore it should 
go in either the UserDomain (bad), in one of the existing Policy 
entities, or as a completely separate entity --- perhaps another 
subclass of Policy.

Providing SLA as an optional String is also not great.  Putting aside 
that an SLA is a multi-dimension thing, just writing down the 
availability (which is what the description hints at) is problematic: 
what is the format of this string? Do I write "0.9999", "99.99", 
"99.99%", "4 nines", "4x9", "max 1 hour total outage every year", ... ?

Doing reasoning with this information is also pretty difficult.

My suggestions are:

   1. don't call it "SLA", but "availability" (or similar).  Using "SLA"
      is asking for trouble.

   2. put it in some Policy entity, not in the object itself.  This
      provides the linkage with the user-community that enjoys this
      SLA.

   3. either call the value a human-readable description of the policy,
      or provide a registry where people can record key-words against
      the corresponding semantics.

The alternative is remove SLA complete and do this outside of GLUE. 
There are languages for handling SLAs; since GLUE provides persistent 
IDs for all objects, these SLA languages should be usable with the GLUE 
ID as the subject.


Files vs Data objects

Renaming files as objects (or "data objects").  I really don't see why 
you want to do this.  It would be better to make sure people understand 
what the term "file" means, rather than simply renaming it.

HTH,

Paul.