[glue-wg] glue2 cloud examples

[Warren Smith]

Our OpenStack installs have flavors defined, but I didn't need to publish this information.

I wanted to provide information about physical nodes so that consumers know how busy a cloud is. This lets us develop displays to show how busy both the available clusters and the available clouds are. In addition, we aren't running Amazon-scale clouds so we do run out of resources sometimes. What do you mean by 'EntityName'? I don't remember what that might refer to and a quick search didn't find it in the GLUE2 spec.

Application Handle/Environment seemed the closest analogy to an image in GLUE2 to me. Not a great fit, of course, but they both identify environments to run in. I haven't thought of it, but I'd probably say that a contextualization of an image is like an input configuration file for an application.


Yeah, I just don't see clouds and grids (and clusters) as all that different with hard lines between them. Jobs are pretty standard by whatever name (job, instance, task, workflow). Clusters often ask for a wall time limit for a task, but not always, while Clouds typically don't ask for a wall time limit for a task, but some do like Nimbus. Some clouds have queues (e.g. Amazon spot instances, Nimbus background instances), some clusters don't use queues (time shared nodes). Some of the traditional cluster scheduling vendors support virtual machines (e.g. HTCondor) and others are integrating themselves into IaaS cloud platforms (e.g. Moab into OpenStack). Grids can have multiple clusters accessed via common mechanisms and a cloud can have multiple availability zones. All of the XaaS services aren't necessarily provided atop IaaS - from what I've read about in the commercial world, some companies tend to do things in virtual machines and others just configure software on bare metal servers.

Yep, the GLUE2 spec is subject to interpretation. I think the working group has the concept of profile documents to let different groups say how they are interpreting it in their situation.


Warren


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

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 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