[glue-wg] glue2 cloud examples

[Warren Smith]

Yep, we couldn't define a GLUE 3 in a short amount of time.

However, I'm not really for formalizing what you've described as GLUE 2.1. If we want to make it an official new version of GLUE, I would push to use the existing GLUE 2 entities wherever possible and just use the extension points in those entities instead of defining new entities (as I did in my approach).

A better strategy may be to call what you are working on "EGI Cloud Extensions to GLUE 2.0" or something - a profile that describes how you use GLUE 2 to describe clouds in EGI. This would let you move forward with some input from the working group, but without needing approval from the working group. We could also see how your cloud profile works and how well my a cloud profile works, without trying to merge them now. We could use this information when we start work on GLUE 3.


Warren

________________________________________
From: Salvatore Pinto [salvatore.pinto at egi.eu]
Sent: Friday, May 02, 2014 10:04 AM
To: Warren Smith; OGF GLUE Working Group
Subject: Re: [glue-wg] glue2 cloud examples

Hi Warren,
I agree with you that the approach of making the existing Computing
entities more abstract (by removing the references to Grid, like Job,
Queue, Wallclock) and then specializing them to the Grid/Cloud
particular use cases would be good, but I am worried that this will need
a big change to the standard, who would lead to a GLUE 3.0 version.
Since in EGI we are still struggling to abandon GLUE 1 for GLUE 2,
producing a new GLUE3 not retro-compatible and asking all the sites to
adapt seems to me a big effort many users will not be willing to take
right now. Also, I guess it will be much more difficult to reach
consensus with such major changes than with just the addition of new
cloud entities.

Maybe we can go step by step, first defining separate cloud entities
(not touching the old grid ones), reaching consensus on what information
should be displayed for the Cloud and what is the meaning of the
entities, so finalizing a GLUE 2.1 retro-compatible with GLUE 2.0 who
can be easily implemented by the FedCloud and existing Grid sites, then
we can work on merging everting togheter in a GLUE 3.0 which abstracts
the Computing entities.

We can discuss about that more at the next teleconference.

Cheers,
   Salvatore.

On 08/04/2014 15:12, Warren Smith wrote:
> One thing I forgot to mention is that going forward, I think a good approach for us to take would be to do something similar to what Salvatore is proposing, but do it across the board. What I mean is that we should abstract the existing entities a little bit and then add entities that are more specialized/concrete. This would allow us to include specialized information in the schema and also provide entities with names that others understand at a glance (if I have to explain what a ComputingActivity/Manager/Service/Share is one more time... :-P). It'll also allow us do any little cleanup changes we've come across in the current schema.
>
> A few quick examples about how this could be done:
>
> current ComputingShare:
>      * create ClusterQueue entity that is a specialization of ComputingShare
>      * create CloudAvailabilityZone entity that is a specialization of ComputingShare?
>      * create CloudTenant entity that is a specialization of ComputingShare (and other entities)
>      * change attribute names containing 'Jobs' to 'Activities'
>      * move 'MappingQueue', '*Slots', '*WaitingTime' to ClusterQueue entity
>
> current ComputingActivity:
>      * create ClusterJob specialization
>      * create GridJob specialization (e.g. a job managed by a grid resource manager/scheduler)
>      * create CloudInstance specialization
>      * move Local* attributes to GridJob
>      * move WaitingPosition to ClusterJob and GridJob
>      * delete ComputingManager*
>      * move ProxyExpirationTime to GridJob
>
> current ExecutionEnvironment:
>      * create ClusterNode specialization (also used for physical nodes in clouds)
>      * create CloudFlavor specialization
>      * remove VirtualMachine attribute
>      * move TotalInstances, UnavailableInstances to ClusterNode
>
>
> I think this will be relatively straightforward to do for the computing and storage entities.
>
> I guess what I'm proposing/asking is if we are talking about making nontrivial changes to the schema, why don't we just start work on GLUE 3.0?
>
>
>
> Warren
>
>
> ________________________________________
> From: Warren Smith
> Sent: Wednesday, March 26, 2014 12:49 PM
> To: OGF GLUE Working Group
> Subject: glue2 cloud examples
>
> Hi all,
>
> I put some examples of how I'm representing an IaaS cloud using GLUE 2 into https://github.com/OGF-GLUE/JSON/tree/master/examples. Look for the files ending in openstack.json and the file images.json. I use a few extensions, but not very many.
>
> My approach is:
>
> Instance/Virtual Machine - ComputingActivity
>
> Physical Node - ExecutionEnvironment
>
> Virtual Machine Image - ApplicationEnvironment/Handle
>
>
> I haven't done anything with storage at this point, but my approach would be to handle an object or image store the same as a shared/parallel file system.
>
>
> I also haven't done anything related to describing virtual networks - GLUE 2 doesn't have much support for describing networks in general. VLANs, overlay networks, etc. are used outside of cloud environments as well as in cloud environments, so I don't know if there would be any need for separate entities/schemas for cloud vs non-cloud environments.
>
>
> Warren
> _______________________________________________
> glue-wg mailing list
> glue-wg at ogf.org
> https://www.ogf.org/mailman/listinfo/glue-wg


--
Salvatore Pinto
Cloud Technologist, EGI.eu
e-mail: salvatore.pinto at egi.eu
skype: salvatore.pinto0
Science Park 140, Amsterdam, The Netherlands