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. On 05/05/2014 17:21, Navarro, John-Paul F. wrote:
On May 2, 2014, at 2:29 PM, Warren Smith <wsmith@tacc.utexas.edu> wrote:
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. The purpose of the GLUE WG group is to provide a forum for sharing diverse requirements and trying to find a common interoperable design. In my view, relinquishing the two current proposal as infrastructure specific profiles, that would not be interoperable, does not accomplish our purpose. I think clouds have been around long enough, and are understood enough, that we could agree on an approach. In fact, it sounds like there are ways to make both approaches work? If this is not the case, we should focus on what requirements can't be met by one of the approaches in tomorrow's meeting.
It seems like both approach provide a mechanism to add necessary entities. It's less clear if both approach can describe the required relationships.
I think we there is room to come to an agreement on a single GLUE 2 compatible and interoperable way to support clouds. I recommend we continue documenting the advantages and short comings of both approaches and try to come to a consensus. Can Salvator and Warren prepare brief list of advantages an disadvantages for both approaches that we could discuss tomorrow? In particular trying to highlight any use cases/requirements that are difficult to satisfy with either approach?
Thanks,
JP
-- Salvatore Pinto Cloud Technologist, EGI.eu e-mail: salvatore.pinto@egi.eu skype: salvatore.pinto0 Science Park 140, Amsterdam, The Netherlands