New version of GLUE 2.1 draft
Dear GLUErs, attached to this mail you will find the latest version of the draft for GLUE 2.1, with the inclusion of the Cloud entities. Respect to the last draft sent, I have performed the following changes (all changes/additions are highlighted in yellow in the document): - I reviewed the representation of the virtual resources available to the VM, and decided to adopt the OpenStack model+GPU, so RAM,CPU,GPU,Network (public or private),OS Disk and Ephemeral disk. This model is the more general I could find between the open source middlewares and should fit almost all of them. - I reviewed the representation of service pricing (costs). The overall pricing issue is quite complex, and a comprehensive standardization of pricing schemes is way out of our scope. Anyway, for brokers and markeplaces to consume this information and select the "best" site for the user, I have included a simple representation via price entities which are associated to the VM image disk and resource. The final price for the VM is calculated as the sum of all the associated price elements (eg. RAM, CPU, OS License, etc...). - I added SLA (service level agreements) related to the cloud service. This is important for brokers (eg. you may select the site with lower price, but only if it provides the SLA you need). I did not standardize SLA representation, but just added a string to represent the SLA, which can be an URL or a short nametag (eg. 99% Avaliability, best effort, etc...). - I added a service ToC parameter as an URL reference to the ToC per the site. When you program a cloud broker, you need your user to accept the ToC of each of the cloud providers at first use. I think GLUE is a nice way for the broker to access the ToC of all the different sites in an uniform way. - I added the possibility to specify pre-set access credentials for the VM images. This information is relevant to the broker system if cloud-init is not supported by the provider or the image. Cheers, Salvatore.
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.
Hi all, On 08/09/14 16:07, Paul Millar wrote:
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.
I found the "languages for handling SLAs" I mentioned: it was the GRAAP-WG, such as WS-Agreement: http://www.ogf.org/documents/GFD.192.pdf and "WS-Agreement Negotiation": http://www.ogf.org/documents/GFD.193.pdf Unfortunately, there seems to be a disconnect between GLUE and GRAAP: I did a simple search for "GLUE" and found no mention in GFD.192. I would have expected some linkage here; for example, GLUE describes a set of objects and GRAAP describes the SLAs and how to negotiate them. Perhaps we should drop them a friendly email... Cheers, Paul.
Perhaps we should drop them a friendly email...
+1 On Mon, Sep 8, 2014 at 5:38 PM, Paul Millar <paul.millar@desy.de> wrote:
Hi all,
On 08/09/14 16:07, Paul Millar wrote:
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.
I found the "languages for handling SLAs" I mentioned: it was the GRAAP-WG, such as WS-Agreement:
http://www.ogf.org/documents/GFD.192.pdf
and "WS-Agreement Negotiation":
http://www.ogf.org/documents/GFD.193.pdf
Unfortunately, there seems to be a disconnect between GLUE and GRAAP: I did a simple search for "GLUE" and found no mention in GFD.192.
I would have expected some linkage here; for example, GLUE describes a set of objects and GRAAP describes the SLAs and how to negotiate them.
Perhaps we should drop them a friendly email...
Cheers,
Paul. _______________________________________________ glue-wg mailing list glue-wg@ogf.org https://www.ogf.org/mailman/listinfo/glue-wg
-- It was a sad and disappointing day when I discovered that my Universal Remote Control did not, in fact, control the Universe. (Not even remotely.)
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.
participants (4)
-
Andre Merzky -
david.meredith＠stfc.ac.uk -
Paul Millar -
Salvatore Pinto