[occi-wg] Cluster kind or such
Csom Gyula
csom at interface.hu
Tue May 11 15:39:26 CDT 2010
Hi!
Just as Andy proposed, I looked thru the Categories section of the spec. and the IETF draft.
Here are my findings:)
---
## Our prerequisites
Our prerequisites are the following:
1. Selected platform: We use OCCI as the cloud interface and OpenNebula as the cloud management
platform.
2. Adhere to the platform: According to the previous messages and the ONE codebase: neither OCCI
nor OpenNebula's OCCI server has explicit cluster entity. Since we want to adhere both to the
specification and to ONE, we "fall back" to single compute entities. That is to say cluster
creation will be made one by one. However we still need atomicity at the server side.
3. Adhere to the platform: ONE uses XML representation format, thus we must follow it...
4. Atomicity: We want the server side processing to happen at "once". Namely the server must either
create the whole cluster (if all necessary resources is available) or it mustn't create at all.
5. Reliability: Finally we want the creation process to be robust. The user must be able to resume
any broken session.
---
## Requirements
The requirements deduced from the previous prerequisites are the following. The following
informations must be presented within each request for cluster compute resources:
6. The identifier of the cluster, in order to group compute resources,
7. The total number of nodes within the cluster and
8. The total number of nodes within the compute type where the current request belongs to.
Notes:
* The last 2 items seem to be necessary to implement atomicity and reliability without tx
support (see below). Eg. the server must know somehow that the cluster request is complete
thus the cluster is ready to be deployed...
* The compute type is like a template for the resource that describes its (default)
characteristics. It is something built into ONE...
Currently I see only 1 alternative to the above approach:
* Introduce transaction logic within the interface. This is complex... and looks similar
to the WS-* path. Well since transaction support doesn't seem to be built into the OCCI
core.
---
## Solution / OCCI extension
Back to our requirements... I see 1 possible extension pathes in order to implement 6.-7.:
10. The compute resource is extended with new attributes. For instance:
* occi.compute.system.name (the cluster name: clusterxxx)
* occi.compute.system.compute_count (the total number of nodes within the cluster)
* occi.compute.instance_type (the instance type: frontend, nas, compute, etc.)
* occi.compute.instance_count (the total number of nodes within the instance type:
1 one for frontend, many for compute nodes)
According to the category header draft the Category header has built in extension support.
Thus the following solution might work without further extending the OCCI interface:
11. The Category element is extended both syntactically and semantically in order to enable
parametrization. Using the http header format a cluster frontend request might look like
this:
Category: compute;
scheme="http://purl.org/occi/kind/";
label="Compute Resource";
instance_type="compute_cluster/frontend_node";
Category: compute_cluster;
scheme="http://example.org/compute_cluster/";
label="Compute Cluster";
name=clusterxxx; (the cluster name)
compute_count=11"; (the total number of nodes)
Category: compute_cluster/frontend_node;
scheme="http://example.org/compute_cluster/";
label="Frontend Resource";
instance_count=1; (the total number of nodes within the frontend_node type)
Here the new element is the attribute, which lets instantiate/describe different category
instances within the same category type. Similarly the compute node requests would look
something like this:
...
Category: compute_cluster/compute_node;
scheme="http://example.org/compute_cluster/";
label="Compute Resource";
instance_count=10; (the total number of nodes within the compute_node type)
The only problem with the latter is its representation format. Since ONE uses XML, we must follow
it. What whould be the category's canonical XML representation format? I looked thru the spec
documents, but found only http header and XHTML formats... Just in case I attached XML samples, too
which extend the XML format used by OpenNebula (frontend.xml, compute.xml)...
Cheers,
Gyula
-----Eredeti üzenet-----
Feladó: Sam Johnston [mailto:samj at samj.net]
Küldve: 2010. 05. 11., K 22:10
Címzett: Edmonds, AndrewX
Másolatot kap: Csom Gyula; occi-wg at ogf.org
Tárgy: Re: [occi-wg] Cluster kind or such
On Tue, May 11, 2010 at 6:54 PM, Edmonds, AndrewX <andrewx.edmonds at intel.com
> wrote:
> Great to have another OCCI adopter on board!
>
+1
> Yes currently there is no _explicit_ representation of a cluster or a
> "system of compute entities" in the specification. What I would suggest is
> two-fold. First, have a look at the section on Categories.
+1 - categories are definitely the best way to model things like clusters,
locations, machine types, operating systems, administrative groupings, etc.
Sam
> -----Original Message-----
> From: occi-wg-bounces at ogf.org [mailto:occi-wg-bounces at ogf.org] On Behalf
> Of Csom Gyula
> Sent: Tuesday, May 11, 2010 3:38 PM
> To: occi-wg at ogf.org
> Subject: [occi-wg] Cluster kind or such
>
> Hi!
>
> We decided to go with the OCCI interface within our cloud implementation
> (and just to be specific we chose OpenNebula as our CMS platform). We hope
> that our selection will prove to be a long term one, thus we'd like to
> adhere to the OCCI specification as much as possible. Meanwhile we have to
> deal with clusters, too, nost just single compute entities. My main question
> is whether you have any plan to incorporate compute systems (like clusters)
> within the OCCI specification?
>
> ---
>
> In our context we'll have to deal with different types of clusters such as
> compute clusters (with one frontend, nas and many compute nodes) and load
> balancing clusters (with one load balancer, many application servers and
> backend storage). In many scenarios these systems must be handled as one
> single entity (eg. must be acquired, deployed at once, must be deleted at
> once, etc.). After all one might consider them as resouces, just like any
> others (compute, storage, and network).
>
> So the question is whether you plan to introduce compute systems or such
> into the specification?
>
> ---
>
> If yes, what will be the shape model? main entities and relations?
>
> For instance in our context all clusters will share the same simple
> structure where a system can be characterized through roles, and node counts
> (per roles). This might be handled by 1 additional main entity (system), and
> 3 pseudo entities (role, compute link and system link).
> See the attached UML diagram: cluster.png. Of course more complex scenarios
> are also possible (peer-to-peer compute relation, system of systems, etc.)
> but such systems are out of our current scope...
>
> ---
>
> In the spec you put the following: "A simple peer review process is
> available for extending the registries which should be used where possible."
> My last question is regarding this
> process:
>
> How does the above peer review work? When and where should someone go to
> make his request?:)
>
> Cheers,
> Gyula
> -------------------------------------------------------------
> Intel Ireland Limited (Branch)
> Collinstown Industrial Park, Leixlip, County Kildare, Ireland
> Registered Number: E902934
>
> This e-mail and any attachments may contain confidential material for
> the sole use of the intended recipient(s). Any review or distribution
> by others is strictly prohibited. If you are not the intended
> recipient, please contact the sender and delete all copies.
>
> _______________________________________________
> occi-wg mailing list
> occi-wg at ogf.org
> http://www.ogf.org/mailman/listinfo/occi-wg
>
-------------- next part --------------
A non-text attachment was scrubbed...
Name: frontend.xml
Type: text/xml
Size: 438 bytes
Desc: frontend.xml
Url : http://www.ogf.org/pipermail/occi-wg/attachments/20100511/5b459526/attachment.xml
-------------- next part --------------
A non-text attachment was scrubbed...
Name: compute.xml
Type: text/xml
Size: 438 bytes
Desc: compute.xml
Url : http://www.ogf.org/pipermail/occi-wg/attachments/20100511/5b459526/attachment-0001.xml
More information about the occi-wg
mailing list