[glue-wg] glue2 cloud examples

[stephen.burke at stfc.ac.uk]

Warren Smith [mailto:wsmith at tacc.utexas.edu] said:
> Another disadvantage of adding new cloud entities to the model is that new
> renderings would also need to be defined.

I would hope that the rendering definitions are generic enough that extending them to include new objects would be straightforward.

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

We deliberately chose fairly abstract names so that they could be used for a range of concepts - but still there are bound to be limits to how far that can be taken.

I would say that the main concepts underlying the existing computing schema are:

A job, being some computing task which is submitted as a request in terms of the required resources, is executed and which then terminates in a relatively short time and frees the resources.

A scheduler, being some software which decides when jobs are executed and on what resources, according to some set of policies.

A set of execution environments, which constitute the computing resources available to execute the jobs. They have defined properties, e.g. CPU type, memory and installed software, and are countable, i.e. you can say how many of each type of resource you have and how many are currently in use.

My impression is that all of those are potentially relevant to clouds, but there may also be significant differences to a traditional cluster system. Probably the biggest potential pinch point is the use of VMs rather than physical hardware. VMs may be created to order so the properties may not be defined in advance, and it may also be hard to decide how to enumerate the size of the available resources.

We could also consider how the information is used. In the grid the traditional uses would be to decide whether a system is capable of running a given job (does it have enough memory, the right OS etc) and to assess how long it might take before the job starts, e.g. queue length. There are also monitoring uses, e.g. to assess the total resources available and the current level of use.

Stephen



-- 
Scanned by iCritical.