[glue-wg] New version of GLUE 2.1 draft

[david.meredith at stfc.ac.uk]

Hi everyone, 

Regarding SLAs:  I support Paul's suggestion to sub-class Policy to derive a new 'SLA/availability' entity that can be liked to a Service Endpoint (e.g. 'SLAPolicy' - call it whatever).  Linking the SE to one or more of these instances could reflect various SLA/availability/pricing levels, e.g. 'Gold, Silver and Bronze'.  

Defining a new Policy sub-class is 100% backward compatible with the existing renderings. Also, this requirement is not limited to Cloud services. For example, EGI are currently investigating the concept of a service registry/marketplace[1][2] for its services.  Since this type of info is largely static, tools such as the GOCDB could use this approach to input/publish this info rather than using the current pilot 'P4U_*' extension properties (P4U = Pay4Use).  Any thoughts/comments from the group before the conf next week would be v.useful.

Thanks, 
David 

[1] https://indico.egi.eu/indico/contributionDisplay.py?sessionId=10&contribId=40&confId=2160  
[2] https://indico.egi.eu/indico/contributionDisplay.py?sessionId=10&contribId=43&confId=2160



> -----Original Message-----
> From: Paul Millar [mailto:paul.millar at desy.de]
> Sent: 08 September 2014 15:07
> To: glue-wg at ogf.org
> Subject: Re: [glue-wg] New version of GLUE 2.1 draft
> 
> 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.
> 
> _______________________________________________
> glue-wg mailing list
> glue-wg at ogf.org
> https://www.ogf.org/mailman/listinfo/glue-wg
-- 
Scanned by iCritical.