[glue-wg] glue2 cloud examples

Warren Smith wsmith at tacc.utexas.edu
Mon Jun 16 21:00:12 EDT 2014



Another disadvantage of adding new cloud entities to the model is that new renderings would also need to be defined.


Comments on your points:

* I've only had to use a couple extensions to represent clouds in the current GLUE2. I've used a few extensions to represent clusters, too (see https://github.com/OGF-GLUE/JSON/tree/master/examples). So, without some examples showing that a lot of extensions are needed, I don't agree with that point.

* I don't think the GLUE2 entity names are self-explanatory in general - I always have to explain what they mean to new users. I don't think this is much worse for a cloud infrastructure than for a cluster or grid.

* I don't quite follow the first advantage you list under "GLUE 2.1". In GLUE 2.0, ComputingActivity (instance) has a RequestedApplicationEnvironment attribute (image). ComputingActivity also has a Share association (inherited from Activity), but I'm not sure what a Share represents here.


Warren

________________________________________
From: Salvatore Pinto [salvatore.pinto at egi.eu]
Sent: Tuesday, May 06, 2014 9:16 AM
To: Navarro, John-Paul F.; Warren Smith
Cc: OGF GLUE Working Group
Subject: Re: [glue-wg] glue2 cloud examples

Hi All,
here my comments to be discussed in today's teleconferece.

Cloud Profile for GLUE 2.0
   Advantages:
     * No need to update the implementation.
     * No need to manage two separate group of entities.
   Disadvantages:
     * Big usage of extended attributes to represent all the needed
additional attributes and many attributes are not needed. Eg. you add
around 3-4 new attributes to each entities and you do not use more than
10 in average.
     * Some attributes names from the implementation
(ApplicationEnvironment, ExecutionEnvironment) will not be
self-explanatory and user will always need to read the profile to
understand the meaning of the implementation.

GLUE 2.1
   Advantages:
     * Possibility to represent a different conceptual model, where the
OS images (application environment) are directly linked to the VM
(computing activity) and to the Share (Computing Share) so to the
Policies (VM can be private and started only to a given share associated
to given VOs)
     * Easier extension to future non-IaaS computing services (with its
own set of resources, you can edit them without messing with the Grid
entities)
   Disadvantages:
     * Need to update the implementation, adding the new cloud entities.
     * Cloud and Grid are seen separated, not as an unique computing
resource.

Cheers,
   Salvatore.



More information about the glue-wg mailing list