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@desy.de] Sent: 08 September 2014 15:07 To: glue-wg@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@ogf.org https://www.ogf.org/mailman/listinfo/glue-wg -- Scanned by iCritical.