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@ogf.org https://www.ogf.org/mailman/listinfo/glue-wg
-- Salvatore Pinto Cloud Technologist, EGI.eu e-mail: salvatore.pinto@egi.eu skype: salvatore.pinto0 Science Park 140, Amsterdam, The Netherlands