Unfortunately my last section under 11. is erroneous (I didn't clean it up)... Sorry for the mistake, and here's the correction: 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. 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) 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) Note: the notes within parenthesis are not part of the requests, are just for explanation purpose. Meanwhile the original question still remains: what will be the XML representation format of Categories? Cheers, Gyula -----Eredeti üzenet----- Feladó: Csom Gyula Küldve: 2010. 05. 11., K 22:39 Címzett: occi-wg@ogf.org Tárgy: RE: [occi-wg] Cluster kind or such 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@samj.net] Küldve: 2010. 05. 11., K 22:10 Címzett: Edmonds, AndrewX Másolatot kap: Csom Gyula; occi-wg@ogf.org Tárgy: Re: [occi-wg] Cluster kind or such On Tue, May 11, 2010 at 6:54 PM, Edmonds, AndrewX <andrewx.edmonds@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@ogf.org [mailto:occi-wg-bounces@ogf.org] On Behalf Of Csom Gyula Sent: Tuesday, May 11, 2010 3:38 PM To: occi-wg@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@ogf.org http://www.ogf.org/mailman/listinfo/occi-wg