Hi Warren, I had a look at your examples and I have some comment: * It seems you are missing the information about the resource templates (OpenStack Flavors), aren't you using these? * Does the user really need the information about the physical node or is this only for administrators and other operational activities? If not, maybe the ExecutionEnvironment can be used to represent the OpenStack falvors. * I see you are using the ApplicationHandle to represent the image identifier, in my first tests I was thinking of using the EntityName for that, since it seems not needed to involved another entity and ApplicationHandle description is related to methods to setup the environment, so maybe more related to Cloud contextualization methods... Beside this particular comments, in general, what I see as reasons for updating GLUE are: 1. Cloud and Grid have different provisioning concepts. Of course, they both offer "Computing resources as a Service", but the overall provisioning concept of Jobs, Wallclock and Queues does not apply to the Cloud IaaS, where provisioning is more flexible and related only to Quotas per user. 2. Cloud is an environment with many services interconnected together and IaaS is the baseline for most of them. So if, in the future, we want to represent other services (like PaaS, iPaaS, VREaaS, LBaaS, and all the other aaS in the world :) ), with their interconnection to the IaaS, I think it could be better to have Cloud IaaS as a new separated set of entities. 3. Since the specification are quite Grid specific, the application to Cloud is subject to "interpretation". For example, to enable BDII in EGI Federated Cloud until the new specification comes out, we are using the old GLUE2.0 schema, but with a different interpretation of the entities than yours (eg. we are using the Execution Environment as VM flavours/resource templates). The fact that two people reading separately the specification interpreted them differently is a fault in the specifications, who needs to ensure interoperability. Cheers, Salvatore. On 26/03/2014 18:49, Warren Smith wrote:
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