February 2010 - occi-wg - lists.ogf.org

[occi] 2 new revisions pushed by s...@samj.net on 2010-02-21 15:33 GMT
by occi＠googlecode.com 21 Feb '10

21 Feb '10

2 new revisions: Revision: 1df85e1a49 Author: Sam Johnston <samj(a)samj.net> Date: Sun Feb 21 07:32:22 2010 Log: Updated affiliation, regenerated. http://code.google.com/p/occi/source/detail?r=1df85e1a49 Revision: 235906a914 Author: Sam Johnston <samj(a)samj.net> Date: Sun Feb 21 07:33:00 2010 Log: merged http://code.google.com/p/occi/source/detail?r=235906a914 ============================================================================== Revision: 1df85e1a49 Author: Sam Johnston <samj(a)samj.net> Date: Sun Feb 21 07:32:22 2010 Log: Updated affiliation, regenerated. http://code.google.com/p/occi/source/detail?r=1df85e1a49 Modified: /docs/occi-application.html /docs/occi-application.pdf /docs/occi-book.html /docs/occi-book.pdf /docs/occi-book.xml ======================================= --- /docs/occi-application.html Sat Oct 10 07:36:28 2009 +++ /docs/occi-application.html Sun Feb 21 07:32:22 2010 @@ -1,7 +1,7 @@ <?xml version="1.0" encoding="UTF-8"?> <!DOCTYPE html PUBLIC "-//W3C//DTD XHTML 1.1//EN" "http://www.w3.org/TR/xhtml11/DTD/xhtml11.dtd"> -<html xmlns="http://www.w3.org/1999/xhtml"><head><title>OCCI Application</title><meta name="generator" content="DocBook XSL-NS Stylesheets V1.75.2"/></head><body><div class="article" title="OCCI Application"><div class="titlepage"><div><div><h2 class="title"><a id="id36063441"/>OCCI Application</h2></div></div><hr/></div><p>The OCCI Application specification defines kinds and extensions - relating to management of cloud application services (SaaS).</p><div class="table"><a id="id36063454"/><p class="title"><b>Table 1. Common Attributes</b></p><div class="table-contents"><table summary="Common Attributes" border="1"><colgroup><col style="text-align: center"/><col/><col/></colgroup><thead><tr><th style="text-align: left">Attribute</th><th>Type</th><th>Description</th></tr></thead><tbody><tr><td style="text-align: left"><code class="computeroutput">occi.application.version</code></td><td>Float (e.g. 1.0)</td><td>Version of the OCCI Application specification</td></tr></tbody></table></div></div><br class="table-break"/><div class="section" title="Kinds"><div class="titlepage"><div><div><h2 class="title"><a id="id36063507"/>Kinds</h2></div></div></div><p>Cloud application services can be modeled using the following - primary kinds:</p><div class="table"><a id="id36063516"/><p class="title"><b>Table 2. Kinds</b></p><div class="table-contents"><table summary="Kinds" border="1"><colgroup><col style="text-align: center"/><col/><col/></colgroup><thead><tr><th style="text-align: left">Kind</th><th>URI</th><th>Description</th></tr></thead><tbody><tr><td style="text-align: left"><code class="computeroutput">contact</code></td><td><code class="uri">http://purl.org/occi/kind/contact</code></td><td>A contact; a person, a venue such as a club or a - restaurant, or an organisation.</td></tr><tr><td style="text-align: left"><code class="computeroutput">document</code></td><td><code class="uri">http://purl.org/occi/kind/document</code></td><td>A word processing document</td></tr><tr><td style="text-align: left"><code class="computeroutput">event</code></td><td><code class="uri">http://purl.org/occi/kind/event</code></td><td>A calendar event</td></tr><tr><td style="text-align: left"><code class="computeroutput">presentation</code></td><td><code class="uri">http://purl.org/occi/kind/presentation</code></td><td>A visual representation</td></tr><tr><td style="text-align: left"><code class="computeroutput">spreadsheet</code></td><td><code class="uri">http://purl.org/occi/kind/spreadsheet</code></td><td>A worksheet</td></tr></tbody></table></div></div><br class="table-break"/><div class="section" title="Contact"><div class="titlepage"><div><div><h3 class="title"><a id="id36063640"/>Contact</h3></div></div></div><p>A contact is a person, venue, organisation, etc.</p></div></div><div class="section" title="Extensions"><div class="titlepage"><div><div><h2 class="title"><a id="id36063651"/>Extensions</h2></div></div></div><p>Various extensions provide for more advanced management - functionality such as billing, monitoring and reporting.</p></div><div class="bibliography" title="Bibliography"><div class="titlepage"><div><div><h2 class="title"><a id="id36063662"/>Bibliography</h2></div></div></div><div class="bibliomixed"><a id="id36063664"/><p class="bibliomixed">Normative References</p></div><div class="bibliomixed"><a id="id36063667"/><p class="bibliomixed">Informative References</p></div><div class="biblioentry" title="Google Data Protocol (GData)"><a id="application-gdata"/><p>[GData] <span class="title"><i>Google Data Protocol (GData)</i>. </span><span class="address"><code class="uri"><a class="uri" href="http://en.wikipedia.org/wiki/List_of_device_bandwidths" target="">http://code.google.com/apis/gdata/</a></code>. </span><span class="author">. </span></p></div></div></div></body></html> +<html xmlns="http://www.w3.org/1999/xhtml"><head><title>OCCI Application</title><meta name="generator" content="DocBook XSL-NS Stylesheets V1.75.2"/></head><body><div class="article" title="OCCI Application"><div class="titlepage"><div><div><h2 class="title"><a id="id36063440"/>OCCI Application</h2></div></div><hr/></div><p>The OCCI Application specification defines kinds and extensions + relating to management of cloud application services (SaaS).</p><div class="table"><a id="id36063453"/><p class="title"><b>Table 1. Common Attributes</b></p><div class="table-contents"><table summary="Common Attributes" border="1"><colgroup><col style="text-align: center"/><col/><col/></colgroup><thead><tr><th style="text-align: left">Attribute</th><th>Type</th><th>Description</th></tr></thead><tbody><tr><td style="text-align: left"><code class="computeroutput">occi.application.version</code></td><td>Float (e.g. 1.0)</td><td>Version of the OCCI Application specification</td></tr></tbody></table></div></div><br class="table-break"/><div class="section" title="Kinds"><div class="titlepage"><div><div><h2 class="title"><a id="id36063506"/>Kinds</h2></div></div></div><p>Cloud application services can be modeled using the following + primary kinds:</p><div class="table"><a id="id36063515"/><p class="title"><b>Table 2. Kinds</b></p><div class="table-contents"><table summary="Kinds" border="1"><colgroup><col style="text-align: center"/><col/><col/></colgroup><thead><tr><th style="text-align: left">Kind</th><th>URI</th><th>Description</th></tr></thead><tbody><tr><td style="text-align: left"><code class="computeroutput">contact</code></td><td><code class="uri">http://purl.org/occi/kind/contact</code></td><td>A contact; a person, a venue such as a club or a + restaurant, or an organisation.</td></tr><tr><td style="text-align: left"><code class="computeroutput">document</code></td><td><code class="uri">http://purl.org/occi/kind/document</code></td><td>A word processing document</td></tr><tr><td style="text-align: left"><code class="computeroutput">event</code></td><td><code class="uri">http://purl.org/occi/kind/event</code></td><td>A calendar event</td></tr><tr><td style="text-align: left"><code class="computeroutput">presentation</code></td><td><code class="uri">http://purl.org/occi/kind/presentation</code></td><td>A visual representation</td></tr><tr><td style="text-align: left"><code class="computeroutput">spreadsheet</code></td><td><code class="uri">http://purl.org/occi/kind/spreadsheet</code></td><td>A worksheet</td></tr></tbody></table></div></div><br class="table-break"/><div class="section" title="Contact"><div class="titlepage"><div><div><h3 class="title"><a id="id36063638"/>Contact</h3></div></div></div><p>A contact is a person, venue, organisation, etc.</p></div></div><div class="section" title="Extensions"><div class="titlepage"><div><div><h2 class="title"><a id="id36063650"/>Extensions</h2></div></div></div><p>Various extensions provide for more advanced management + functionality such as billing, monitoring and reporting.</p></div><div class="bibliography" title="Bibliography"><div class="titlepage"><div><div><h2 class="title"><a id="id36063660"/>Bibliography</h2></div></div></div><div class="bibliomixed"><a id="id36063662"/><p class="bibliomixed">Normative References</p></div><div class="bibliomixed"><a id="id36063666"/><p class="bibliomixed">Informative References</p></div><div class="biblioentry" title="Google Data Protocol (GData)"><a id="application-gdata"/><p>[GData] <span class="title"><i>Google Data Protocol (GData)</i>. </span><span class="address"><code class="uri"><a class="uri" href="http://en.wikipedia.org/wiki/List_of_device_bandwidths" target="">http://code.google.com/apis/gdata/</a></code>. </span><span class="author">. </span></p></div></div></div></body></html> ======================================= --- /docs/occi-application.pdf Sat Oct 10 07:36:28 2009 +++ /docs/occi-application.pdf Sun Feb 21 07:32:22 2010 Binary file, no diff available. ======================================= --- /docs/occi-book.html Wed Oct 28 18:16:54 2009 +++ /docs/occi-book.html Sun Feb 21 07:32:22 2010 @@ -1,11 +1,11 @@ <?xml version="1.0" encoding="UTF-8"?> <!DOCTYPE html PUBLIC "-//W3C//DTD XHTML 1.1//EN" "http://www.w3.org/TR/xhtml11/DTD/xhtml11.dtd"> -<html xmlns="http://www.w3.org/1999/xhtml"><head><title>OGF OCCI-WG Deliverables</title><meta name="generator" content="DocBook XSL-NS Stylesheets V1.75.2"/></head><body><div class="book" title="OGF OCCI-WG Deliverables"><div class="titlepage"><div><div><h1 class="title"><a id="id36063441"/>OGF OCCI-WG Deliverables</h1></div><div><div class="author"><h3 class="author"><span class="firstname">Sam</span> <span class="surname">Johnston</span></h3><span class="contrib">WG Secretary</span> <span class="contrib">Author</span> <div class="affiliation"><span class="orgname">Australian Online Solutions<br/></span></div></div></div><div><div class="author"><h3 class="author"><span class="firstname">Thijs</span> <span class="surname">Metsch</span></h3><span class="contrib">Co-Chair</span> <span class="contrib">Author</span> <div class="affiliation"><span class="orgname">Sun Microsystems<br/></span></div></div></div><div><div class="author"><h3 class="author"><span class="firstname">Andrew</span> <span class="surname">Edmonds</span></h3><span class="contrib">Co-Chair</span> <span class="contrib">Author</span> <div class="affiliation"><span class="orgname">Intel<br/></span></div></div></div><div><div class="author"><h3 class="author"><span class="firstname">Alexis</span> <span class="surname">Richardson</span></h3><span class="contrib">Co-Chair</span> <div class="affiliation"><span class="orgname">Rabbit Technologies<br/></span></div></div></div><div><p class="pubdate">July 2009</p></div></div><hr/></div><div class="article" title="OCCI Use Cases"><div class="titlepage"><div><div><h2 class="title"><a id="id36063864"/>OCCI Use Cases</h2></div></div><hr/></div><p>The following section describes the Use Cases which were gathered +<html xmlns="http://www.w3.org/1999/xhtml"><head><title>OGF OCCI-WG Deliverables</title><meta name="generator" content="DocBook XSL-NS Stylesheets V1.75.2"/></head><body><div class="book" title="OGF OCCI-WG Deliverables"><div class="titlepage"><div><div><h1 class="title"><a id="id36063440"/>OGF OCCI-WG Deliverables</h1></div><div><div class="author"><h3 class="author"><span class="firstname">Sam</span> <span class="surname">Johnston</span></h3><span class="contrib">WG Secretary</span> <span class="contrib">Author</span> <div class="affiliation"><span class="orgname">Google<br/></span></div></div></div><div><div class="author"><h3 class="author"><span class="firstname">Thijs</span> <span class="surname">Metsch</span></h3><span class="contrib">Co-Chair</span> <span class="contrib">Author</span> <div class="affiliation"><span class="orgname">Sun Microsystems<br/></span></div></div></div><div><div class="author"><h3 class="author"><span class="firstname">Andrew</span> <span class="surname">Edmonds</span></h3><span class="contrib">Co-Chair</span> <span class="contrib">Author</span> <div class="affiliation"><span class="orgname">Intel<br/></span></div></div></div><div><div class="author"><h3 class="author"><span class="firstname">Alexis</span> <span class="surname">Richardson</span></h3><span class="contrib">Co-Chair</span> <div class="affiliation"><span class="orgname">Rabbit Technologies<br/></span></div></div></div><div><p class="pubdate">July 2009</p></div></div><hr/></div><div class="article" title="OCCI Use Cases"><div class="titlepage"><div><div><h2 class="title"><a id="id36063862"/>OCCI Use Cases</h2></div></div><hr/></div><p>The following section describes the Use Cases which were gathered during the requirements analyses for the OCCI working group. They are used to set up the requirements and later on to verify the OCCI - specification.</p><div class="section" title="SLA-aware cloud infrastructure using SLA@SOI"><div class="titlepage"><div><div><h2 class="title"><a id="id36065051"/>SLA-aware cloud infrastructure using SLA@SOI</h2></div></div></div><p>There is a need for a standard interface for dynamic infrastructure + specification.</p><div class="section" title="SLA-aware cloud infrastructure using SLA@SOI"><div class="titlepage"><div><div><h2 class="title"><a id="id36065047"/>SLA-aware cloud infrastructure using SLA@SOI</h2></div></div></div><p>There is a need for a standard interface for dynamic infrastructure provisioning. While doing so it must be guaranteed and verified that the - infrastructure provisioning uses 'machine-readable' SLAs. <span class="citerefentry"><span class="refentrytitle">(SLA_SOI)</span></span></p><h3><a id="id36065067"/>Functional Requirements</h3><div class="itemizedlist"><ul class="itemizedlist"><li class="listitem"><p>VM Description: request format important - In this area is where + infrastructure provisioning uses 'machine-readable' SLAs. <sup>[<a id="id36065057" href="#ftn.id36065057" class="footnote">1</a>]</sup></p><h3><a id="id36065064"/>Functional Requirements</h3><div class="itemizedlist"><ul class="itemizedlist"><li class="listitem"><p>VM Description: request format important - In this area is where there is least coherency amongst providers.</p></li><li class="listitem"><p>VM Description: a means to add non-functional constraints on functional attributes.</p></li><li class="listitem"><p>VM Management: all parameters in the request should be "monitor-able" and verifiable. Full control of resources (VMs) @@ -14,20 +14,20 @@ defaults of public and private further sub-categorisation could be allowed e.g. tag of web could be assigned to the public network group.</p></li><li class="listitem"><p>Storage Management: simple mount points, reuse storage SaaS - offerings</p></li></ul></div><h3><a id="id36065121"/>Non-functional Requirements</h3><div class="itemizedlist"><ul class="itemizedlist"><li class="listitem"><p>Security: Transport and user level (ACLs? oAuth?) + offerings</p></li></ul></div><h3><a id="id36065118"/>Non-functional Requirements</h3><div class="itemizedlist"><ul class="itemizedlist"><li class="listitem"><p>Security: Transport and user level (ACLs? oAuth?) security</p></li><li class="listitem"><p>Quality of Service: Can be many - Part of service offering from the infrastructure provider e.g. Security, QoS, geo-location, isolation levels - NFPs are the basic building blocks of differentiating IaaS providers.</p></li><li class="listitem"><p>Scheduling Information: When a particular resource is to be run. Also in which order should a collection of resources be ran in the - case that one resource is dependent on another.</p></li></ul></div></div><div class="section" title="Service Manager to control the Life cycle of Services"><div class="titlepage"><div><div><h2 class="title"><a id="id36065154"/>Service Manager to control the Life cycle of Services</h2></div></div></div><p>This Use Case is based in the 'Service Manager' (SM) layer of the + case that one resource is dependent on another.</p></li></ul></div></div><div class="section" title="Service Manager to control the Life cycle of Services"><div class="titlepage"><div><div><h2 class="title"><a id="id36065151"/>Service Manager to control the Life cycle of Services</h2></div></div></div><p>This Use Case is based in the 'Service Manager' (SM) layer of the RESERVOIR project architecture. 'Service Providers' (SP) willing to deploy their service on the Cloud use this layer to control the service life cycle. The SM operates over the Cloud infrastructure automatically as the service demands. In a way, the SM maps the service configuration and needs to calls to the Cloud infrastructure, so many of the requirements imposed - by the SM are due to the flexibility that the SM aims to provide to SPs. - (<span class="citerefentry"><span class="refentrytitle">RV</span></span>)</p><h3><a id="id36065175"/>Functional Requirements</h3><div class="itemizedlist"><ul class="itemizedlist"><li class="listitem"><p>Network Management: There should be methods for the Allocation + by the SM are due to the flexibility that the SM aims to provide to + SPs.<sup>[<a id="id36065164" href="#ftn.id36065164" class="footnote">2</a>]</sup></p><h3><a id="id36065172"/>Functional Requirements</h3><div class="itemizedlist"><ul class="itemizedlist"><li class="listitem"><p>Network Management: There should be methods for the Allocation of private networks, where VMs can be attached to. A special network (e.g. 'Public Network') should be available. When some network interface is attached to it, the infrastructure must assign a public @@ -72,7 +72,7 @@ IDs, (UUIDs, URIs, or the like). It is to be determined whether components of VMs (disks, memory...) should have an unique ID too. IDs are assigned by the Cloud infrastructure when the corresponding - element is created.</p></li></ul></div><h3><a id="id36065349"/>Non-functional Requirements</h3><div class="itemizedlist"><ul class="itemizedlist"><li class="listitem"><p>Both for hardware configuration and monitoring values there + element is created.</p></li></ul></div><h3><a id="id36065346"/>Non-functional Requirements</h3><div class="itemizedlist"><ul class="itemizedlist"><li class="listitem"><p>Both for hardware configuration and monitoring values there should be a clear, standard way to set which magnitude the value represents. For example, when setting the memory size to '2', it must be clear that we refer to GBs and not to MBs. An option would be @@ -80,7 +80,7 @@ value and the magnitude: value '2' and magnitude 'GB'.</p></li><li class="listitem"><p>Protocols: The transport, message format, and state representation should use open and standard protocols, each one which strong software support (i.e. libraries and frameworks available for - several programming languages).</p></li></ul></div></div><div class="section" title="Interoperability across Cloud Infrastructures using OpenNebula"><div class="titlepage"><div><div><h2 class="title"><a id="id36065377"/>Interoperability across Cloud Infrastructures using + several programming languages).</p></li></ul></div></div><div class="section" title="Interoperability across Cloud Infrastructures using OpenNebula"><div class="titlepage"><div><div><h2 class="title"><a id="id36065373"/>Interoperability across Cloud Infrastructures using OpenNebula</h2></div></div></div><p>OpenNebula is a Virtual Infrastructure Engine, being enhanced in the RESERVOIR project, which allows the management of Virtual Machines on a pool of physical resources It offers three main functionalities: backend @@ -93,7 +93,7 @@ OpenNebula to manage Virtual Machines from different cloud providers. Currently, there are two set of plugins for OpenNebula to access Amazon EC2 and ElasticHosts cloud providers that leverage the use of both cloud - providers in a transparent fashion for the end user. (<span class="citerefentry"><span class="refentrytitle">ONE</span></span>)</p><h3><a id="id36065405"/>Functional Requirements</h3><div class="itemizedlist"><ul class="itemizedlist"><li class="listitem"><p>VM Description: Virtual Machines should be described + providers in a transparent fashion for the end user.<sup>[<a id="id36065393" href="#ftn.id36065393" class="footnote">3</a>]</sup></p><h3><a id="id36065400"/>Functional Requirements</h3><div class="itemizedlist"><ul class="itemizedlist"><li class="listitem"><p>VM Description: Virtual Machines should be described consistently across cloud providers using a slim set of indispensable attributes, such as:</p><div class="itemizedlist"><ul class="itemizedlist"><li class="listitem"><p>Memory: Amount of RAM needed by the Virtual Machine</p></li><li class="listitem"><p>CPU: Number of CPUs needed by the Virtual Machine (this needs to be normalized)</p></li><li class="listitem"><p>Disk: Disks that will conform the basic filesystem and @@ -111,61 +111,61 @@ fundamental to virtual machine management to avoid the need to reinstall software for each cloud provider. The upload process should return an identifier to be used in the Virtual Machine - Description.</p></li></ul></div><h3><a id="id36065615"/>Non-functional Requirements</h3><div class="itemizedlist"><ul class="itemizedlist"><li class="listitem"><p>Security: Security should be handled using X509 certificates for + Description.</p></li></ul></div><h3><a id="id36065610"/>Non-functional Requirements</h3><div class="itemizedlist"><ul class="itemizedlist"><li class="listitem"><p>Security: Security should be handled using X509 certificates for authentication. Also, authorization can be based on said certificates and ACL lists.</p></li><li class="listitem"><p>Quality of Service: When used in conjunction with Haizea, OpenNebula provides advanced reservation functionality. Cloud providers API should provide similar capabilities to ensure proper - QoS.</p></li></ul></div></div><div class="section" title="AJAX web front-end directly calling API"><div class="titlepage"><div><div><h2 class="title"><a id="id36065640"/>AJAX web front-end directly calling API</h2></div></div></div><p>This Use Case describes the ability to create web front-ends for + QoS.</p></li></ul></div></div><div class="section" title="AJAX web front-end directly calling API"><div class="titlepage"><div><div><h2 class="title"><a id="id36065635"/>AJAX web front-end directly calling API</h2></div></div></div><p>This Use Case describes the ability to create web front-ends for Clouds. A cloud provider implements their customer web front-end as an entirely client-side AJAX application calling the OCCI API - directly.</p><h3><a id="id36065651"/>Functional Requirements</h3><div class="itemizedlist"><ul class="itemizedlist"><li class="listitem"><p>Completeness: API must be contain complete set of calls to + directly.</p><h3><a id="id36065646"/>Functional Requirements</h3><div class="itemizedlist"><ul class="itemizedlist"><li class="listitem"><p>Completeness: API must be contain complete set of calls to completely specify and control cloud (but this is likely only ~15-20 verbs on ~3-4 nouns!)</p></li><li class="listitem"><p>Responsiveness: Calls must return swiftly. In particular, we should provide a simple and quick call to poll the _list_ of servers, drives, etc. that exist without listing all of their properties, since this is computationally much cheaper for the cloud to return, and will need to be regularly polled to catch any servers, etc. that are - created outside of the interface.</p></li></ul></div><h3><a id="id36065677"/>Non-functional Requirements</h3><div class="itemizedlist"><ul class="itemizedlist"><li class="listitem"><p>Syntax: A simple JSON syntax for the API will make the AJAX - interface much simpler to implement</p></li></ul></div></div><div class="section" title="Single technical integration to support multiple service providers"><div class="titlepage"><div><div><h2 class="title"><a id="id36065693"/>Single technical integration to support multiple service + created outside of the interface.</p></li></ul></div><h3><a id="id36065672"/>Non-functional Requirements</h3><div class="itemizedlist"><ul class="itemizedlist"><li class="listitem"><p>Syntax: A simple JSON syntax for the API will make the AJAX + interface much simpler to implement</p></li></ul></div></div><div class="section" title="Single technical integration to support multiple service providers"><div class="titlepage"><div><div><h2 class="title"><a id="id36065688"/>Single technical integration to support multiple service providers</h2></div></div></div><p>Today, each cloud provider (ElasticHosts, GoGrid, Amazon, etc.) integrates independently with every other player in the cloud ecosystem (CohesiveFT, RightScale, etc), producing O(n^2) separate technical integrations. In the future, if all cloud providers and cloud ecosystem partners use a single standard API, then we have O(n) technical integrations, and all potential partnerships can immediately - interoperate.</p><h3><a id="id36065706"/>Non-functional Requirements</h3><div class="itemizedlist"><ul class="itemizedlist"><li class="listitem"><p>Uptake: Standardized IaaS API needs strong uptake in by both - cloud providers and cloud ecosystem.</p></li></ul></div></div><div class="section" title="Wrapping EC2 in OCCI"><div class="titlepage"><div><div><h2 class="title"><a id="id36065722"/>Wrapping EC2 in OCCI</h2></div></div></div><p>At the time of this writing, Amazon EC2 is popular cloud API for + interoperate.</p><h3><a id="id36065701"/>Non-functional Requirements</h3><div class="itemizedlist"><ul class="itemizedlist"><li class="listitem"><p>Uptake: Standardized IaaS API needs strong uptake in by both + cloud providers and cloud ecosystem.</p></li></ul></div></div><div class="section" title="Wrapping EC2 in OCCI"><div class="titlepage"><div><div><h2 class="title"><a id="id36065717"/>Wrapping EC2 in OCCI</h2></div></div></div><p>At the time of this writing, Amazon EC2 is popular cloud API for IaaS. Cloud providers implementing EC2 as well as other proprietary and open cloud APIs may not implement OCCI. To help ensure that the OCCI API would be capable of interfacing to EC2 though gateways, minimizing the - impact to provider operations. </p><h3><a id="id36065734"/>Functional Requirements</h3><div class="itemizedlist"><ul class="itemizedlist"><li class="listitem"><p>Semantics: Must include the ability to fully describe core EC2 - objects and operations</p></li></ul></div><h3><a id="id36065749"/>Non-functional Requirements</h3><div class="itemizedlist"><ul class="itemizedlist"><li class="listitem"><p>A gateway to support the integration of OCCI and EC2</p></li></ul></div></div><div class="section" title="Automated Business Continuity and Disaster Recovery"><div class="titlepage"><div><div><h2 class="title"><a id="id36065764"/>Automated Business Continuity and Disaster Recovery</h2></div></div></div><p>Maintain a up-to-date remote shadows of physical and/or virtual + impact to provider operations.</p><h3><a id="id36065729"/>Functional Requirements</h3><div class="itemizedlist"><ul class="itemizedlist"><li class="listitem"><p>Semantics: Must include the ability to fully describe core EC2 + objects and operations</p></li></ul></div><h3><a id="id36065744"/>Non-functional Requirements</h3><div class="itemizedlist"><ul class="itemizedlist"><li class="listitem"><p>A gateway to support the integration of OCCI and EC2</p></li></ul></div></div><div class="section" title="Automated Business Continuity and Disaster Recovery"><div class="titlepage"><div><div><h2 class="title"><a id="id36065759"/>Automated Business Continuity and Disaster Recovery</h2></div></div></div><p>Maintain a up-to-date remote shadows of physical and/or virtual machines, such that in the event of a disaster it is possible to start and - switch to the remote machines.</p><h3><a id="id36065775"/>Functional Requirements</h3><div class="itemizedlist"><ul class="itemizedlist"><li class="listitem"><p>VM Description: Metadata mapping to legacy systems</p></li><li class="listitem"><p>VM Management: Automated management in the event of a disaster + switch to the remote machines.</p><h3><a id="id36065770"/>Functional Requirements</h3><div class="itemizedlist"><ul class="itemizedlist"><li class="listitem"><p>VM Description: Metadata mapping to legacy systems</p></li><li class="listitem"><p>VM Management: Automated management in the event of a disaster (e.g. startup, IP changes).</p></li><li class="listitem"><p>Network Management: Runtime alteration of IPs</p></li><li class="listitem"><p>Image Management: Advanced, rsync style updates to synchronise machines with physical equivalents (e.g. rsync block devices to remote - raw disk files).</p></li></ul></div><h3><a id="id36065813"/>Non-functional Requirements</h3><div class="itemizedlist"><ul class="itemizedlist"><li class="listitem"><p>Quality of Service: Reservation of capacity sufficient for fail - over</p></li></ul></div></div><div class="section" title="Simple scripting of cloud from Unix shell"><div class="titlepage"><div><div><h2 class="title"><a id="id36065829"/>Simple scripting of cloud from Unix shell</h2></div></div></div><p>An end user wishes to script a simple task (such as starting a + raw disk files).</p></li></ul></div><h3><a id="id36065808"/>Non-functional Requirements</h3><div class="itemizedlist"><ul class="itemizedlist"><li class="listitem"><p>Quality of Service: Reservation of capacity sufficient for fail + over</p></li></ul></div></div><div class="section" title="Simple scripting of cloud from Unix shell"><div class="titlepage"><div><div><h2 class="title"><a id="id36065824"/>Simple scripting of cloud from Unix shell</h2></div></div></div><p>An end user wishes to script a simple task (such as starting a server at midnight every night and shutting it down an hour later, automating fail over, reporting, etc.). They are using a typical Unix/Linux setup, so would like to write a simple cron job which carries - this out.</p><h3><a id="id36065840"/>Non-functional Requirements</h3><div class="itemizedlist"><ul class="itemizedlist"><li class="listitem"><p>Syntax: This should be as simple as possible to place minimal + this out.</p><h3><a id="id36065836"/>Non-functional Requirements</h3><div class="itemizedlist"><ul class="itemizedlist"><li class="listitem"><p>Syntax: This should be as simple as possible to place minimal barriers to entry on the user. The user should not need any development tools or libraries. They should be able to write 1-2 lines of shell script, posting a simple <5 lines of command data using - curl, wget, etc.</p></li></ul></div></div><div class="section" title="Typical web hosting cluster"><div class="titlepage"><div><div><h2 class="title"><a id="id36065858"/>Typical web hosting cluster</h2></div></div></div><p>An end-user runs a typical web hosting cluster on a cloud, with: n + curl, wget, etc.</p></li></ul></div></div><div class="section" title="Typical web hosting cluster"><div class="titlepage"><div><div><h2 class="title"><a id="id36065853"/>Typical web hosting cluster</h2></div></div></div><p>An end-user runs a typical web hosting cluster on a cloud, with: n database servers, m front-end web server (bursting to x under load) and a load balancer (either a specialized virtual machine or provided by the - cloud like GoGrid).</p><h3><a id="id36065870"/>Functional Requirements</h3><div class="itemizedlist"><ul class="itemizedlist"><li class="listitem"><p>Completeness: The API should be able to fully express this + cloud like GoGrid).</p><h3><a id="id36065865"/>Functional Requirements</h3><div class="itemizedlist"><ul class="itemizedlist"><li class="listitem"><p>Completeness: The API should be able to fully express this cluster, which will require at least: (n+m+x) virtual machines, storage for each virtual machine, two networks (a private one connecting the machines, and the public Internet also connected to the load balancer), a fixed static IP for the website on the public - Internet, possible specification of the load balancer itself.</p></li></ul></div></div><div class="section" title="Manage cloud resources from a centralized dashboard"><div class="titlepage"><div><div><h2 class="title"><a id="id36065888"/>Manage cloud resources from a centralized dashboard</h2></div></div></div><p>An end user wishes to view and control all of his cloud-based + Internet, possible specification of the load balancer itself.</p></li></ul></div></div><div class="section" title="Manage cloud resources from a centralized dashboard"><div class="titlepage"><div><div><h2 class="title"><a id="id36065883"/>Manage cloud resources from a centralized dashboard</h2></div></div></div><p>An end user wishes to view and control all of his cloud-based resources in a lightweight (perhaps AJAX-based) console, perhaps the same web front-end referred to in this Use Case: AJAX web front-end directly - calling API</p><h3><a id="id36065900"/>Functional Requirements</h3><div class="itemizedlist"><ul class="itemizedlist"><li class="listitem"><p>Completeness: Every resource provided by the cloud is + calling API</p><h3><a id="id36065895"/>Functional Requirements</h3><div class="itemizedlist"><ul class="itemizedlist"><li class="listitem"><p>Completeness: Every resource provided by the cloud is discoverable by the API, and every action that can be performed on all these resources is also available via the API, together with actuators to actually perform those actions, and all the attributes of the @@ -175,18 +175,17 @@ this is computationally much cheaper for the cloud to return, and will need to be regularly polled to catch any servers, etc. that are created outside of the interface. (text copied from AJAX web front-end - directly calling API)</p></li><li class="listitem"><p>Categorizability: (there's gotta be a better word...) The client - must be able to identify what type each resource is in order to - display like-typed resources together and in order to provide separate - UI views that might be specialized for certain resource types. For - example, the client must be able to differentiate between a compute - resource that does not represent an actual CPU (perhaps this is a - compute template) and between a compute resource that actually - represents a running CPU. The interface for actually-running CPUs - might display the current IP address of the instance and allow you to - SSH into the instance, while a different tab in the interface might - display all the compute templates and allow you to instantiate - instances from them.</p></li><li class="listitem"><p>Taggability: Every resource discoverable by the API must be able + directly calling API)</p></li><li class="listitem"><p>Categorizability: The client must be able to identify what type + each resource is in order to display like-typed resources together and + in order to provide separate UI views that might be specialized for + certain resource types. For example, the client must be able to + differentiate between a compute resource that does not represent an + actual CPU (perhaps this is a compute template) and between a compute + resource that actually represents a running CPU. The interface for + actually-running CPUs might display the current IP address of the + instance and allow you to SSH into the instance, while a different tab + in the interface might display all the compute templates and allow you + to instantiate instances from them.</p></li><li class="listitem"><p>Taggability: Every resource discoverable by the API must be able to be tagged by the user. This supports the oft-occurring situation where resources, though they are identified by the implementation-specific identifier, are easily identified using @@ -197,43 +196,43 @@ allow an optional filter that can specify a category or tag upon which to filter the results. This allows one to further limit their view to, for example, resources tagged "productionEnvironment", or resources of - the category "storage".</p></li></ul></div><h3><a id="id36065962"/>Non-functional Requirements</h3><div class="itemizedlist"><ul class="itemizedlist"><li class="listitem"><p>Usability: This should be a user interface with context-menus + the category "storage".</p></li></ul></div><h3><a id="id36065957"/>Non-functional Requirements</h3><div class="itemizedlist"><ul class="itemizedlist"><li class="listitem"><p>Usability: This should be a user interface with context-menus and context-aware links that allow the user to easily see what actions - can be performed for each resource.</p></li></ul></div></div><div class="section" title="Compute Cloud"><div class="titlepage"><div><div><h2 class="title"><a id="id36065979"/>Compute Cloud</h2></div></div></div><p>A cloud provider implements a RESTful API for provisioning, - executing, and monitoring of tasks.</p><h3><a id="id36065989"/>Functional Requirements</h3><div class="itemizedlist"><ul class="itemizedlist"><li class="listitem"><p>Secure: API must be secured to ensure that only authorized + can be performed for each resource.</p></li></ul></div></div><div class="section" title="Compute Cloud"><div class="titlepage"><div><div><h2 class="title"><a id="id36065973"/>Compute Cloud</h2></div></div></div><p>A cloud provider implements a RESTful API for provisioning, + executing, and monitoring of tasks.</p><h3><a id="id36065983"/>Functional Requirements</h3><div class="itemizedlist"><ul class="itemizedlist"><li class="listitem"><p>Secure: API must be secured to ensure that only authorized identities are permitted to use the API.</p></li><li class="listitem"><p>Resource: An endpoint must be created for external monitoring, status, and auditing of the task. This endpoint would be responsive to RESTful calls supporting AJAX and other clients.</p></li><li class="listitem"><p>Scripted: The target system needs to understand and process directives which would be provided with the task. These directives would include the ability to pull binaries or data onto the system, - run executables, and status the system resources.</p></li></ul></div><h3><a id="id36066021"/>Non-functional Requirements</h3><div class="itemizedlist"><ul class="itemizedlist"><li class="listitem"><p>Single Compute Method: The resultant service should be the same + run executables, and status the system resources.</p></li></ul></div><h3><a id="id36066016"/>Non-functional Requirements</h3><div class="itemizedlist"><ul class="itemizedlist"><li class="listitem"><p>Single Compute Method: The resultant service should be the same service that can be used for many other purposes. It could be used for monitoring of system health, system life-cycle management, system patching, and configuration changes. If this was the only service on the system initially, it could then be used to build up the other - services in a plug-in manner.</p></li></ul></div></div><div class="section" title="Multiple Allocation"><div class="titlepage"><div><div><h2 class="title"><a id="id36066040"/>Multiple Allocation</h2></div></div></div><p>Allocate a whole cluster with one call.</p><h3><a id="id36066049"/>Functional Requirements</h3><div class="itemizedlist"><ul class="itemizedlist"><li class="listitem"><p>Definition of groups: There should be a way to define groups of + services in a plug-in manner.</p></li></ul></div></div><div class="section" title="Multiple Allocation"><div class="titlepage"><div><div><h2 class="title"><a id="id36066034"/>Multiple Allocation</h2></div></div></div><p>Allocate a whole cluster with one call.</p><h3><a id="id36066044"/>Functional Requirements</h3><div class="itemizedlist"><ul class="itemizedlist"><li class="listitem"><p>Definition of groups: There should be a way to define groups of computers. In the example of a cluster, there would be two groups: The Headnode and a couple of Workernodes.</p></li><li class="listitem"><p>Information: For configuration of the members of the defined groups, there should be way (maybe a URL) to find out about all groups and their basic configurations. In the example, the Headnode would want to know IPs or Hostnames of all Workernodes. The workernodes will need to know this, as well _and_ they need to know, that the headnode - is in a different group.</p></li></ul></div></div><div class="section" title="Cloud Consumer Discovery of Cloud Provider's VM Input and Output Format Support"><div class="titlepage"><div><div><h2 class="title"><a id="id36066076"/>Cloud Consumer Discovery of Cloud Provider's VM Input and Output + is in a different group.</p></li></ul></div></div><div class="section" title="Cloud Consumer Discovery of Cloud Provider's VM Input and Output Format Support"><div class="titlepage"><div><div><h2 class="title"><a id="id36066071"/>Cloud Consumer Discovery of Cloud Provider's VM Input and Output Format Support</h2></div></div></div><p>A cloud consumer would like to discover the VM input and output - formats accepted and delivered by the cloud provider.</p><h3><a id="id36066087"/>Functional Requirements</h3><div class="itemizedlist"><ul class="itemizedlist"><li class="listitem"><p>The provider supplies an API which is availed over unsecured + formats accepted and delivered by the cloud provider.</p><h3><a id="id36066082"/>Functional Requirements</h3><div class="itemizedlist"><ul class="itemizedlist"><li class="listitem"><p>The provider supplies an API which is availed over unsecured network connections.</p></li><li class="listitem"><p>The provider supplies an API which is availed over secured network connections.</p></li><li class="listitem"><p>The provider supplied API is availed for all consumer authentication and authorization levels.</p></li><li class="listitem"><p>The provider supplied API identifies the supported VM input formats API uniquely and commonly across all providers.</p></li><li class="listitem"><p>The provider supplied API identifies the supported VM output formats API uniquely and commonly across all providers.</p></li><li class="listitem"><p>The provider supplied API identifies the supported VM formats - uniquely and commonly across all providers.</p></li><li class="listitem"><p>The provider API identifies mutliple supported VM input formats + uniquely and commonly across all providers.</p></li><li class="listitem"><p>The provider API identifies multiple supported VM input formats as a list uniquely and commonly across all providers</p></li><li class="listitem"><p>The provider API identifier is unique and and consistent across all API representations.</p></li><li class="listitem"><p>The provider API VM input and output format identifiers are unique and and consistent across all providers.</p></li><li class="listitem"><p>The reported VM input and output formats are not required to be - symetrical and equal and in consistent order.</p></li></ul></div></div><div class="section" title="Cloud Consumer Discovery of Cloud Provider's Dataset Input and Output Format Support"><div class="titlepage"><div><div><h2 class="title"><a id="id36066173"/>Cloud Consumer Discovery of Cloud Provider's Dataset Input and + symetrical and equal and in consistent order.</p></li></ul></div></div><div class="section" title="Cloud Consumer Discovery of Cloud Provider's Dataset Input and Output Format Support"><div class="titlepage"><div><div><h2 class="title"><a id="id36066168"/>Cloud Consumer Discovery of Cloud Provider's Dataset Input and Output Format Support</h2></div></div></div><p>A cloud consumer would like to discover the Dataset input and output formats accepted and delivered by the cloud - provider.</p><h3><a id="id36066183"/>Functional Requirements</h3><div class="itemizedlist"><ul class="itemizedlist"><li class="listitem"><p>The provider supplies an API which is availed over unsecured + provider.</p><h3><a id="id36066178"/>Functional Requirements</h3><div class="itemizedlist"><ul class="itemizedlist"><li class="listitem"><p>The provider supplies an API which is availed over unsecured network connections.</p></li><li class="listitem"><p>The provider supplies an API which is availed over secured network connections.</p></li><li class="listitem"><p>The provider supplied API is availed for all consumer authentication and authorization levels.</p></li><li class="listitem"><p>The provider supplied API identifies the supported Dataset @@ -244,8 +243,8 @@ as a list uniquely and commonly across all providers</p></li><li class="listitem"><p>The provider API identifier is unique and and consistent across all API representations.</p></li><li class="listitem"><p>The provider API Dataset input and output format identifiers are unique and and consistent across all providers.</p></li><li class="listitem"><p>The reported Dataset input and output formats are not required - to be symetrical and equal and in consistent order.</p></li></ul></div></div></div><div class="article" title="OCCI Requirements"><div class="titlepage"><div><div><h2 class="title"><a id="id36063880"/>OCCI Requirements</h2></div></div><hr/></div><div class="section" title="Functional Requirements"><div class="titlepage"><div><div><h2 class="title"><a id="id36066814"/>Functional Requirements</h2></div></div></div><p>This section deals with the funtional requirements. The requirments - have been split up in tables and prioritized.</p><div class="table"><a id="id36066824"/><p class="title"><b>Table 1. Functional requirements on VM description</b></p><div class="table-contents"><table summary="Functional requirements on VM description" border="1"><colgroup><col/><col/><col/><col/></colgroup><thead><tr><th style="text-align: center">ID</th><th style="text-align: center">Description</th><th style="text-align: center">Usecases</th><th style="text-align: center">Priority</th></tr></thead><tbody><tr><td>A.1.1</td><td>Attributes to define memory, CPU, disk and network + to be symetrical and equal and in consistent order.</p></li></ul></div></div><div class="footnotes"><br/><hr/><div class="footnote"><p><sup>[<a id="ftn.id36065057" href="#id36065057" class="para">1</a>] </sup>SLA@SOI project website - http://sla-at-soi.eu</p></div><div class="footnote"><p><sup>[<a id="ftn.id36065164" href="#id36065164" class="para">2</a>] </sup>RESERVOIR project website - http://www.reservoir-fp7.eu</p></div><div class="footnote"><p><sup>[<a id="ftn.id36065393" href="#id36065393" class="para">3</a>] </sup>OpenNebula website - http://www.opennebula.org</p></div></div></div><div class="article" title="OCCI Requirements"><div class="titlepage"><div><div><h2 class="title"><a id="id36063879"/>OCCI Requirements</h2></div></div><hr/></div><div class="section" title="Functional Requirements"><div class="titlepage"><div><div><h2 class="title"><a id="id36066810"/>Functional Requirements</h2></div></div></div><p>This section deals with the funtional requirements. The requirements + have been split up in tables and prioritized.</p><div class="table"><a id="id36066820"/><p class="title"><b>Table 1. Functional requirements on VM description</b></p><div class="table-contents"><table summary="Functional requirements on VM description" border="1"><colgroup><col/><col/><col/><col/></colgroup><thead><tr><th style="text-align: center">ID</th><th style="text-align: center">Description</th><th style="text-align: center">Usecases</th><th style="text-align: center">Priority</th></tr></thead><tbody><tr><td>A.1.1</td><td>Attributes to define memory, CPU, disk and network requirements should be available.</td><td>2.2, 2.3, 2.6</td><td>High</td></tr><tr><td>A.1.2.</td><td>Attributes to define placement constraints, such as geographical location must be supported</td><td>2.2</td><td>Medium</td></tr><tr><td>A.1.3.</td><td>A attributes should demonstrate if migration is supported by the infrastructure</td><td>2.2</td><td>Medium</td></tr><tr><td>A.1.4.</td><td>The API should be able to fully express a cluster (e.g. 5 @@ -257,7 +256,7 @@ provisioned resources to be execute sometime in the future from the original request</td><td>2.1</td><td>Medium</td></tr><tr><td>A.1.7.</td><td>Common operating systems should be supported</td><td>-</td><td>High</td></tr><tr><td>A.1.8.</td><td>Resources should be grouped according to provider policies</td><td>-</td><td>High</td></tr><tr><td>A.1.9.</td><td>Then requesting new resource(s) the request must be fully - complete/describing</td><td>-</td><td>High</td></tr></tbody></table></div></div><br class="table-break"/><div class="table"><a id="id36067066"/><p class="title"><b>Table 2. Functional requirements on VM management</b></p><div class="table-contents"><table summary="Functional requirements on VM management" border="1"><colgroup><col/><col/><col/><col/></colgroup><thead><tr><th style="text-align: center">ID</th><th style="text-align: center">Description</th><th style="text-align: center">Usecases</th><th style="text-align: center">Priority</th></tr></thead><tbody><tr><td>A.2.1.</td><td>Methods to start, stop, suspend and resume VMs must be + complete/describing</td><td>-</td><td>High</td></tr></tbody></table></div></div><br class="table-break"/><div class="table"><a id="id36067062"/><p class="title"><b>Table 2. Functional requirements on VM management</b></p><div class="table-contents"><table summary="Functional requirements on VM management" border="1"><colgroup><col/><col/><col/><col/></colgroup><thead><tr><th style="text-align: center">ID</th><th style="text-align: center">Description</th><th style="text-align: center">Usecases</th><th style="text-align: center">Priority</th></tr></thead><tbody><tr><td>A.2.1.</td><td>Methods to start, stop, suspend and resume VMs must be available</td><td>2.1, 2.2, 2.3, 2.5, 2.11, 2.10</td><td>High</td></tr><tr><td>A.2.2.</td><td>Automated management in the event of a disaster should be supported</td><td>2.1, 2.7</td><td>Low</td></tr><tr><td>A.2.3.</td><td>Provide IDs for each backup disk and images</td><td>2.2</td><td>High</td></tr><tr><td>A.2.4.</td><td>Provide methods to donwload any backup</td><td>2.2</td><td>Medium</td></tr><tr><td>A.2.5.</td><td>API should offer functionality to enforce the following operations: deploy, shutdown, cancel, checkpoint, save, restore, @@ -271,153 +270,162 @@ Interoperability)</td><td>-</td><td>Medium</td></tr><tr><td>A.2.11.</td><td>Support a subset of all functions of today IaaS based Clouds (e.g. Amaton EC2)</td><td>2.6</td><td>Medium</td></tr><tr><td>A.2.12.</td><td>A common interface should be used which can be supported by many Cloud service providers (regarding Infrastructure and Data - interfaces).</td><td>2.13, 2.14</td><td>Medium</td></tr></tbody></table></div></div><br class="table-break"/><div class="table"><a id="id36067354"/><p class="title"><b>Table 3. Functional requirements on Network management</b></p><div class="table-contents"><table summary="Functional requirements on Network management" border="1"><colgroup><col/><col/><col/><col/></colgroup><thead><tr><th style="text-align: center">ID</th><th style="text-align: center">Description</th><th style="text-align: center">Usecases</th><th style="text-align: center">Priority</th></tr></thead><tbody><tr><td>A.3.1.</td><td>Support the creation of VPNs</td><td>2.3</td><td>Low</td></tr><tr><td>A.3.2.</td><td>Support multiple network connection (Public and + interfaces).</td><td>2.13, 2.14</td><td>Medium</td></tr></tbody></table></div></div><br class="table-break"/><div class="table"><a id="id36067350"/><p class="title"><b>Table 3. Functional requirements on Network management</b></p><div class="table-contents"><table summary="Functional requirements on Network management" border="1"><colgroup><col/><col/><col/><col/></colgroup><thead><tr><th style="text-align: center">ID</th><th style="text-align: center">Description</th><th style="text-align: center">Usecases</th><th style="text-align: center">Priority</th></tr></thead><tbody><tr><td>A.3.1.</td><td>Support the creation of VPNs</td><td>2.3</td><td>Low</td></tr><tr><td>A.3.2.</td><td>Support multiple network connection (Public and Private)</td><td>2.1, 2.2, 2.3</td><td>High</td></tr><tr><td>A.3.3.</td><td>It must be possible to attach and change IPs at runtime</td><td>2.3, 2.7</td><td>Medium</td></tr><tr><td>A.3.4.</td><td>Support a tagging mechanism for a group of network connections</td><td>2.1, 2.2, 2.3</td><td>Low</td></tr><tr><td>A.3.5.</td><td>Support network setups which allow an 'Intercloud' setup - (This relates to Integration)</td><td>-</td><td>Medium</td></tr></tbody></table></div></div><br class="table-break"/><div class="table"><a id="id36067513"/><p class="title"><b>Table 4. Functional requirements on Storage management</b></p><div class="table-contents"><table summary="Functional requirements on Storage management" border="1"><colgroup><col/><col/><col/><col/></colgroup><thead><tr><th style="text-align: center">ID</th><th style="text-align: center">Description</th><th style="text-align: center">Usecases</th><th style="text-align: center">Priority</th></tr></thead><tbody><tr><td>A.4.1.</td><td>Allow the usage of URIs as mount points - allows reuse of + (This relates to Integration)</td><td>-</td><td>Medium</td></tr></tbody></table></div></div><br class="table-break"/><div class="table"><a id="id36067509"/><p class="title"><b>Table 4. Functional requirements on Storage management</b></p><div class="table-contents"><table summary="Functional requirements on Storage management" border="1"><colgroup><col/><col/><col/><col/></colgroup><thead><tr><th style="text-align: center">ID</th><th style="text-align: center">Description</th><th style="text-align: center">Usecases</th><th style="text-align: center">Priority</th></tr></thead><tbody><tr><td>A.4.1.</td><td>Allow the usage of URIs as mount points - allows reuse of Storage service offerings</td><td>2.1</td><td>High</td></tr><tr><td>A.4.2.</td><td>Allow the attachment of additional storage resources at - runtime</td><td>-</td><td>Medium</td></tr></tbody></table></div></div><br class="table-break"/><div class="table"><a id="id36067619"/><p class="title"><b>Table 5. Functional requirements on Image management</b></p><div class="table-contents"><table summary="Functional requirements on Image management" border="1"><colgroup><col/><col/><col/><col/></colgroup><thead><tr><th style="text-align: center">ID</th><th style="text-align: center">Description</th><th style="text-align: center">Usecases</th><th style="text-align: center">Priority</th></tr></thead><tbody><tr><td>A.5.1.</td><td>Methods which are capable to register, upload, update and + runtime</td><td>-</td><td>Medium</td></tr></tbody></table></div></div><br class="table-break"/><div class="table"><a id="id36067615"/><p class="title"><b>Table 5. Functional requirements on Image management</b></p><div class="table-contents"><table summary="Functional requirements on Image management" border="1"><colgroup><col/><col/><col/><col/></colgroup><thead><tr><th style="text-align: center">ID</th><th style="text-align: center">Description</th><th style="text-align: center">Usecases</th><th style="text-align: center">Priority</th></tr></thead><tbody><tr><td>A.5.1.</td><td>Methods which are capable to register, upload, update and download disk images must be available.</td><td>2.2</td><td>Medium</td></tr><tr><td>A.5.2.</td><td>Updates based on rsync commands to synchronize machines with physical equivalents should be supported</td><td>2.7</td><td>Medium</td></tr><tr><td>A.5.3.</td><td>When an upload completes successfully, an identifier should - be returned</td><td>2.2</td><td>Low</td></tr></tbody></table></div></div><br class="table-break"/><div class="table"><a id="id36067744"/><p class="title"><b>Table 6. Identifications/References</b></p><div class="table-contents"><table summary="Identifications/References" border="1"><colgroup><col/><col/><col/><col/></colgroup><thead><tr><th style="text-align: center">ID</th><th style="text-align: center">Description</th><th style="text-align: center">Usecases</th><th style="text-align: center">Priority</th></tr></thead><tbody><tr><td>A.6.1.</td><td>Unique IDs for VM images and their components must be + be returned</td><td>2.2</td><td>Low</td></tr></tbody></table></div></div><br class="table-break"/><div class="table"><a id="id36067739"/><p class="title"><b>Table 6. Identifications/References</b></p><div class="table-contents"><table summary="Identifications/References" border="1"><colgroup><col/><col/><col/><col/></colgroup><thead><tr><th style="text-align: center">ID</th><th style="text-align: center">Description</th><th style="text-align: center">Usecases</th><th style="text-align: center">Priority</th></tr></thead><tbody><tr><td>A.6.1.</td><td>Unique IDs for VM images and their components must be available</td><td>2.2, 2.13, 2.14</td><td>High</td></tr><tr><td>A.6.2.</td><td>It must be possbile to tag resources and their components</td><td>2.10, 2.12</td><td>Medium</td></tr><tr><td>A.6.3.</td><td>It must be possible to search for resources based on e.g. - tags.</td><td>2.10, 2.12</td><td>Medium</td></tr></tbody></table></div></div><br class="table-break"/><div class="table"><a id="id36067867"/><p class="title"><b>Table 7. Monitoring</b></p><div class="table-contents"><table summary="Monitoring" border="1"><colgroup><col/><col/><col/><col/></colgroup><thead><tr><th style="text-align: center">ID</th><th style="text-align: center">Description</th><th style="text-align: center">Usecases</th><th style="text-align: center">Priority</th></tr></thead><tbody><tr><td>A.7.1.</td><td>Support pull-based monitoring that request the status of + tags.</td><td>2.10, 2.12</td><td>Medium</td></tr></tbody></table></div></div><br class="table-break"/><div class="table"><a id="id36067863"/><p class="title"><b>Table 7. Monitoring</b></p><div class="table-contents"><table summary="Monitoring" border="1"><colgroup><col/><col/><col/><col/></colgroup><thead><tr><th style="text-align: center">ID</th><th style="text-align: center">Description</th><th style="text-align: center">Usecases</th><th style="text-align: center">Priority</th></tr></thead><tbody><tr><td>A.7.1.</td><td>Support pull-based monitoring that request the status of the elements such as network , VM ...</td><td>2.1, 2.2, 2.3</td><td>Medium</td></tr><tr><td>A.7.2.</td><td>Support for a publish/subscribe pattern that request events which occur in the VM or networks (such as Errors on some component, changes in the VM state and other periodic notifications)</td><td>2.2</td><td>Medium</td></tr><tr><td>A.7.3.</td><td>Attributes that define simple quick call to poll the list of servers, drives, etc should monitorable</td><td>2.4</td><td>Low</td></tr><tr><td>A.7.4.</td><td>Attributes about resource consumption of the VM from the hypervisor (CPU, memory...) should be monitorable</td><td>2.1, 2.2</td><td>Medium</td></tr><tr><td>A.7.5.</td><td>Management reports should be generated from in some of the - following formats XML, PDF</td><td>-</td><td>Low</td></tr></tbody></table></div></div><br class="table-break"/></div><div class="section" title="Non-functional Requirements"><div class="titlepage"><div><div><h2 class="title"><a id="id36068030"/>Non-functional Requirements</h2></div></div></div><p>This section deals with all the non-funtional requirements.</p><div class="table"><a id="id36068040"/><p class="title"><b>Table 8. Security requirements</b></p><div class="table-contents"><table summary="Security requirements" border="1"><colgroup><col/><col/><col/><col/></colgroup><thead><tr><th style="text-align: center">ID</th><th style="text-align: center">Description</th><th style="text-align: center">Usecases</th><th style="text-align: center">Priority</th></tr></thead><tbody><tr><td>B.1.1.</td><td>Support the usage of X509 Certificates</td><td>2.3, 2.13, 2.14</td><td>High</td></tr><tr><td>B.1.2.</td><td>Support the usage of ACLs</td><td>B.1, 2.1</td><td>High</td></tr><tr><td>B.1.3.</td><td>Attributes to define Security levels should be available in - the descriptions</td><td>2.1</td><td>High</td></tr><tr><td>B.1.4.</td><td>Transport and user level security should be given</td><td>2.1, 2.13, 2.14</td><td>High</td></tr><tr><td>B.1.5.</td><td>Allow geographical region to be specified</td><td>B.4</td><td>High</td></tr></tbody></table></div></div><br class="table-break"/><div class="table"><a id="id36068198"/><p class="title"><b>Table 9. Quality of Service</b></p><div class="table-contents"><table summary="Quality of Service" border="1"><colgroup><col/><col/><col/><col/></colgroup><thead><tr><th style="text-align: center">ID</th><th style="text-align: center">Description</th><th style="text-align: center">Usecases</th><th style="text-align: center">Priority</th></tr></thead><tbody><tr><td>B.2.1.</td><td>Support capacities requirements for recovery / failover + following formats XML, PDF</td><td>-</td><td>Low</td></tr></tbody></table></div></div><br class="table-break"/></div><div class="section" title="Non-functional Requirements"><div class="titlepage"><div><div><h2 class="title"><a id="id36068026"/>Non-functional Requirements</h2></div></div></div><p>This section deals with all the non-funtional requirements.</p><div class="table"><a id="id36068035"/><p class="title"><b>Table 8. Security requirements</b></p><div class="table-contents"><table summary="Security requirements" border="1"><colgroup><col/><col/><col/><col/></colgroup><thead><tr><th style="text-align: center">ID</th><th style="text-align: center">Description</th><th style="text-align: center">Usecases</th><th style="text-align: center">Priority</th></tr></thead><tbody><tr><td>B.1.1.</td><td>Support the usage of X509 Certificates</td><td>2.3, 2.13, 2.14</td><td>High</td></tr><tr><td>B.1.2.</td><td>Support the usage of ACLs</td><td>B.1, 2.1</td><td>High</td></tr><tr><td>B.1.3.</td><td>Attributes to define Security levels should be available in + the descriptions</td><td>2.1</td><td>High</td></tr><tr><td>B.1.4.</td><td>Transport and user level security should be given</td><td>2.1, 2.13, 2.14</td><td>High</td></tr><tr><td>B.1.5.</td><td>Allow geographical region to be specified</td><td>B.4</td><td>High</td></tr></tbody></table></div></div><br class="table-break"/><div class="table"><a id="id36068194"/><p class="title"><b>Table 9. Quality of Service</b></p><div class="table-contents"><table summary="Quality of Service" border="1"><colgroup><col/><col/><col/><col/></colgroup><thead><tr><th style="text-align: center">ID</th><th style="text-align: center">Description</th><th style="text-align: center">Usecases</th><th style="text-align: center">Priority</th></tr></thead><tbody><tr><td>B.2.1.</td><td>Support capacities requirements for recovery / failover cases</td><td>2.7</td><td>Low</td></tr><tr><td>B.2.2.</td><td>Support of attributes in the VM description to define QoS level (this also includes the reponse times)</td><td>2.1</td><td>High</td></tr><tr><td>B.2.3.</td><td>Support of attributes in the VM describing the Isolation level</td><td>2.1</td><td>Medium</td></tr><tr><td>B.2.4.</td><td>Support of attributes for an advanced reservation - functionality</td><td>2.3</td><td>Low</td></tr><tr><td>B.2.5.</td><td>Allow VM response times to be specified</td><td>B.4</td><td>High</td></tr></tbody></table></div></div><br class="table-break"/><div class="table"><a id="id36068357"/><p class="title"><b>Table 10. Syntax</b></p><div class="table-contents"><table summary="Syntax" border="1"><colgroup><col/><col/><col/><col/></colgroup><thead><tr><th style="text-align: center">ID</th><th style="text-align: center">Description</th><th style="text-align: center">Usecases</th><th style="text-align: center">Priority</th></tr></thead><tbody><tr><td>B.3.1.</td><td>No development tools or libraries should be needed by the + functionality</td><td>2.3</td><td>Low</td></tr><tr><td>B.2.5.</td><td>Allow VM response times to be specified</td><td>B.4</td><td>High</td></tr></tbody></table></div></div><br class="table-break"/><div class="table"><a id="id36068353"/><p class="title"><b>Table 10. Syntax</b></p><div class="table-contents"><table summary="Syntax" border="1"><colgroup><col/><col/><col/><col/></colgroup><thead><tr><th style="text-align: center">ID</th><th style="text-align: center">Description</th><th style="text-align: center">Usecases</th><th style="text-align: center">Priority</th></tr></thead><tbody><tr><td>B.3.1.</td><td>No development tools or libraries should be needed by the end-user</td><td>2.8</td><td>Medium</td></tr><tr><td>B.3.2.</td><td>Support simple JSON syntax to suppot Ajax interface</td><td>2.4, 2.10</td><td>Medium</td></tr><tr><td>B.3.3.</td><td>Clear definition of units (MB, GB etc) should be used in - the requests (Like those defined by IEC 60027-2 A.2)</td><td>A.2, 2.4</td><td>Medium</td></tr></tbody></table></div></div><br class="table-break"/><div class="table"><a id="id36068481"/><p class="title"><b>Table 11. Backup/Disaster recovery</b></p><div class="table-contents"><table summary="Backup/Disaster recovery" border="1"><colgroup><col/><col/><col/><col/></colgroup><thead><tr><th style="text-align: center">ID</th><th style="text-align: center">Description</th><th style="text-align: center">Usecases</th><th style="text-align: center">Priority</th></tr></thead><tbody><tr><td>B.4.1.</td><td>Support a backup functionality of cloud resources</td><td>-</td><td>Low</td></tr><tr><td>B.4.2.</td><td>The interface should reconsider failover, disaster recovery - and business continuity plans</td><td>-</td><td>Medium</td></tr></tbody></table></div></div><br class="table-break"/></div></div><div class="article" title="OCCI Walkthrough"><div class="titlepage"><div><div><h2 class="title"><a id="id36066277"/>OCCI Walkthrough</h2></div></div><hr/></div><div class="section" title="Overview"><div class="titlepage"><div><div><h2 class="title"><a id="id36066634"/>Overview</h2></div><div><h3 class="subtitle">THIS WALKTHROUGH DOCUMENT DOES NOT REFLECT THE CURRENT STATE OF + the requests (Like those defined by IEC 60027-2 A.2)</td><td>A.2, 2.4</td><td>Medium</td></tr></tbody></table></div></div><br class="table-break"/><div class="table"><a id="id36068476"/><p class="title"><b>Table 11. Backup/Disaster recovery</b></p><div class="table-contents"><table summary="Backup/Disaster recovery" border="1"><colgroup><col/><col/><col/><col/></colgroup><thead><tr><th style="text-align: center">ID</th><th style="text-align: center">Description</th><th style="text-align: center">Usecases</th><th style="text-align: center">Priority</th></tr></thead><tbody><tr><td>B.4.1.</td><td>Support a backup functionality of cloud resources</td><td>-</td><td>Low</td></tr><tr><td>B.4.2.</td><td>The interface should reconsider failover, disaster recovery + and business continuity plans</td><td>-</td><td>Medium</td></tr></tbody></table></div></div><br class="table-break"/></div></div><div class="article" title="OCCI Walkthrough"><div class="titlepage"><div><div><h2 class="title"><a id="id36066264"/>OCCI Walkthrough</h2></div></div><hr/></div><div class="section" title="Overview"><div class="titlepage"><div><div><h2 class="title"><a id="id36066681"/>Overview</h2></div><div><h3 class="subtitle">THIS WALKTHROUGH DOCUMENT DOES NOT REFLECT THE CURRENT STATE OF THE SPECIFICATION. IT WILL BE UPDATED ON PUBLICATION.</h3></div></div></div><p>The Open Cloud Computing Interface (OCCI) is an API for managing cloud infrastructure services (also known as Infrastructure as a Service - or IaaS) which strictly adheres to REpresentational State Transfer (REST) + or IaaS), which strictly adheres to REpresentational State Transfer (REST) principles and is closely tied to HyperText Tranfer Protocol (HTTP). For simplicity and scalability reasons it specifically avoids Remote Procedure Call (RPC) style interfaces and can essentially be implemented as a horizontally scalable document repository with which both nodes and clients interact.</p><p>This document describes a step-by-step walkthrough of performing - various tasks as at the time of writing.</p></div><div class="section" title="Getting Started"><div class="titlepage"><div><div><h2 class="title"><a id="id36066657"/>Getting Started</h2></div></div></div><h3><a id="id36066663"/>Connecting</h3><p>Each implementation has a single OCCI end-point URL (we'll use - http://example.com/) and everything you need to know is linked from this + various tasks as at the time of writing.</p></div><div class="section" title="Getting Started"><div class="titlepage"><div><div><h2 class="title"><a id="id36066705"/>Getting Started</h2></div></div></div><h3><a id="id36066710"/>Connecting</h3><p>Each implementation has a single OCCI end-point URL (we'll use + http://example.com/) and everything needed to know is linked from this point - configuring clients is just a case of providing this parameter. In - the simplest case the end-point may contain only a single resource or type - of resource (e.g. a hypervisor burnt into the BIOS of a motherboard - exposing compute resources, a network switch/router exposing network - resources or a SAN exposing storage resources) and at the other end of the - spectrum it may provide access to a global cloud infrastructure (e.g. the + the simplest case, the end-point may contain only a single resource, for + example, a hypervisor burnt into the BIOS of a motherboard that exposes + compute resources, a network switch/router exposing network resources or a + SAN exposing storage resources. At the other end of the spectrum the + end-point may provide access to a global cloud infrastructure (e.g. the "Great Global Grid" or GGG). You will only ever see those resources to which you have access to (typically all of them for a private cloud or a - small subset for a public cloud) and flexible categorisation and search - provide fine-grained control which resources are returned, allowing OCCI - to handle the largest of installations. You will always connect to this - end-point over HTTP(S) and given the simplicity of the interface most - user-agents are suitable, including libraries (e.g. urllib2, LWP), command - line tools (e.g. curl, wget) and full blown browsers (e.g. - Firefox).</p><h3><a id="id36066669"/>Authenticating</h3><p>When you connect you will normally be challenged to authenticate via + small subset for a public cloud) and flexible categorisation. The search + extension provides fine-grained control which resources are returned, + allowing OCCI to handle the largest of installations. The end-point is + always connected over HTTP(S) and given the simplicity of the interface + most user-agents are suitable, including libraries (e.g. urllib2, LWP), + command line tools (e.g. curl, wget) and full blown browsers (e.g. + Firefox).</p><h3><a id="id36066717"/>Authenticating</h3><p>When you connect you will normally be challenged to authenticate via HTTP (this is not always the case - in secure/offline environments it may not be necessary) and will need to do so via the specified mechanism. It is anticipated that most implementations will require HTTP Basic - Authentication over SSL/TLS so at the very least you should support this - (fortunately almost all user-agents already do), but more advanced - mechanisms such as NTLM or Kerberos may be deployed. Certain types of - accesses (such as a compute resource querying OCCI for introspection and - configuration) may be possible anonymously (having already been - authenticated by interface and/or IP address). Should you be redirected by - the API to a node, storage device, etc. (for example, to retrieve a large - binary representation) then you should either be able to transparently - authenticate or a signed URL should be provided. That is, a single set of - credentials is all that is required to access the entire system from any - point.</p><h3><a id="id36066676"/>Representations</h3><p>As the resource itself (e.g. a physical machine, storage array or - network switch) cannot be transferred over HTTP (at least not yet!) we - instead make available one or more representations of that resource. For - example, an API modeling a person might return a picture, fingerprints, - identity document(s) or even a digitised DNA sequence, but not the person - themselves. A circle might be represented by SVG drawing primatives or any - three distinct points on the curve. For cloud infrastructure there are - many useful representations, and while OCCI standardises a number of them - for interoperability purposes, an implementation is free to implement - others in order to best serve the specific needs of their users and to + Authentication over SSL/TLS so at the very least you should support this, + but more advanced mechanisms such as NTLM or Kerberos may be deployed. + Certain types of accesses such as a compute resource querying OCCI for + introspection and configuration may be possible anonymously but only + having already been authenticated by interface and/or IP address. Should + you be redirected by the API to a node, storage device, etc. (for example, + to retrieve a large binary representation) then the OCCI provider should + provide means to transparently authenticate the currently authenticated + user. That is, a single set of credentials and a single sign-on is all + that is required to access the entire system from any point.</p><h3><a id="id36066724"/>Representations</h3><p>As the resource itself (e.g. a physical machine, storage array or + network switch) cannot be transferred over HTTP we instead make available + one or more representations of that resource. For example, an API modeling + a person might return a picture, fingerprints, identity document(s) or + even a digitised DNA sequence, but not the person themselves. A circle + might be represented by SVG drawing primatives or any three distinct + points on the curve. For cloud infrastructure there are many useful + representations, and while OCCI recommends a number of them for + interoperability purposes, an implementation is free to implement others + in order to best serve the specific needs of their users and to differentiate from other offerings. Other examples include:</p><div class="itemizedlist"><ul class="itemizedlist"><li class="listitem"><p>Open Cloud Computing Interface (OCCI) descriptor format (application/occi+xml)</p></li><li class="listitem"><p>Open Virtualisation Format (OVF) file (application/ovf+xml?)</p></li><li class="listitem"><p>Open Virtualisation Archive (OVA) file - (application/x-ova?)</p></li><li class="listitem"><p>Screenshot of the console (image/png)</p></li><li class="listitem"><p>Access to the console (application/x-vnc)</p></li></ul></div><p>The client indicates which representation(s) it desires by way of - the URL and/or HTTP Accept headers (e.g. HTTP Content Negotiation) and if - the server is unable to satisfy the request then it should return HTTP 406 - Not Acceptable.</p><h3><a id="id36066735"/>Descriptors</h3><p>In addition to the protocol itself, OCCI defines a simple key/value - based descriptor format for cloud infrastructure resources:</p><div class="glosslist"><dl><dt>compute</dt><dd><p>Provides computational services, ranging from dedicated + (application/x-ova?)</p></li></ul></div><p>Other, albeit lesser representations, could include:</p><div class="itemizedlist"><ul class="itemizedlist"><li class="listitem"><p>Screenshot of the console (image/png)</p></li><li class="listitem"><p>Access to the console (application/x-vnc)</p></li></ul></div><p>The client indicates which representation(s) it desires by way of + HTTP Content Negotiation using the HTTP Accept header and if the server is + unable to satisfy the request then it should return HTTP 406 Not + Acceptable. The client can also request the rendering via URL extension, + if the server supports this option.</p><h3><a id="id36066791"/>Descriptors</h3><p>OCCI defines a simple attribute-based (key/value) descriptor format + for cloud infrastructure resources. These infrastructure resources as + defined by OCCI are:</p><div class="glosslist"><dl><dt><span class="bold"><strong>Compute:</strong></span></dt><dd><p>Provides computational services, ranging from dedicated physical machines (e.g. Dedibox) to virtual machines (e.g. Amazon - EC2) to slices/zones/containers (e.g. Mosso Cloud Servers).</p></dd><dt>network</dt><dd><p>Provides connectivity between machines and the outside world. + EC2) to slices/zones/containers (e.g. Mosso Cloud Servers).</p></dd><dt><span class="bold"><strong>Network:</strong></span></dt><dd><p>Provides connectivity between machines and the outside world. Usually virtual and may or may not be connected to a physical - segment.</p></dd><dt>storage</dt><dd><p>Provides storage services, typically via magnetic mass storage + segment.</p></dd><dt><span class="bold"><strong>Storage:</strong></span></dt><dd><p>Provides storage services, typically via magnetic mass storage devices (e.g. hard drives, RAID arrays, SANs).</p></dd></dl></div><p>Given the simplicity of the format it is trivial to translate - between wire formats including plain text, JSON, XML and others. For + between wire formats including plain text, JSON, XML and others + <em><span class="remark"><--| Insert alternative examples | --></span></em> . For example:</p><pre class="screen">occi.compute.cores 2 compute.speed 3200 -compute.memory 2048</pre><h3><a id="id36066800"/>Identifiers</h3><p>Each resource is identified by its dereferenceable URL which is by +compute.memory 2048</pre><h3><a id="id36064816"/>Identifiers</h3><p>Each resource is identified by its dereferenceable URL which is by definition unique, giving information about the origin and type of the - resource as well as a local identifier (the combination of which forms a - globally unique compound key). The primary drawback is that the more - information that goes into the key (and therefore the more transparent it - is), the more likely it is to change. For example, if you migrate a - resource from one implementation to another then its identifier will - change (though in this instance the source should provide a HTTP 301 Moved - Permanently response along with the new location, assuming it is known, or - HTTP 410 Gone otherwise).</p><p>In order to realise the benefit of transparent, dereferenceable + resource as well as a local identifier. The combination of both forms a + globally unique compound key.<em><span class="remark"> <--| Is this necessary + here?</span></em> The primary drawback is that the more information that goes + into the key (and therefore the more transparent it is), the more likely + it is to change. For example, if you migrate a resource from one + implementation to another then its identifier will change (though in this + instance the source should provide a HTTP 301 Moved Permanently response + along with the new location, assuming it is known, or HTTP 410 Gone + otherwise).<em><span class="remark">|--></span></em></p><p>In order to realise the benefit of transparent, dereferenceable identifiers while still being able to track resources through their entire lifecycle an immutable UUID attribute should be allocated which will remain with the resource throughout its life. This is particularly important where the same resource (e.g. a network) appears in multiple - places.</p><p>New implementations should use type 4 (random) UUIDs anyway, as - these can be safely allocated by any node without consulting a - register/sequence, but where existing identifiers are available they - should be used instead (e.g. - http://amazon.com/compute/ami-ef48af86)</p></div><div class="section" title="Operations"><div class="titlepage"><div><div><h2 class="title"><a id="id36064772"/>Operations</h2></div></div></div><h3><a id="id36064777"/>Create</h3><p>To create a resource simply POST it to the appropropriate collection - (e.g. /compute, /network or /storage) as an HTML form (supported by - virtually all user agents) or in another supported format (e.g. - OVF):</p><pre class="screen">POST /compute HTTP/1.1 + places.</p><p>New implementations should use type-4 random UUIDs, as these can be + safely allocated by any OCCI-compliant provider without consulting a + register/sequence. Where existing identifiers are available they should be + used instead (e.g. + http://an.occi.provider.com/compute/ami-ef48af86)</p></div><div class="section" title="Operations"><div class="titlepage"><div><div><h2 class="title"><a id="id36064848"/>Operations</h2></div></div></div><h3><a id="id36064854"/>Create</h3><p>To create a resource simply POST the resource representation to the + appropriate collection (e.g. /compute, /network or /storage) using the + application/x- www-form-urlencoded format (used by HTML forms) or in + another supported format (e.g. OVF):</p><pre class="screen">POST /compute HTTP/1.1 Host: example.com Content-Length: 35 Content-Type: application/x-www-form-urlencoded compute.cores=2&compute.memory=2048</pre><p>Rather than generating the new resource from scratch you may also be - given the option to GET a template and POST or PUT it back (for example, - where "small", "medium" and "large" instances or pre-configured appliances - are offered).</p><h3><a id="id36064797"/>Retrieve</h3><p>The simplest command is to retrieve a single resource by conducting + given the option <em><span class="remark"><--| Templates are not explained in the + walkthrough </span></em>to GET a template <em><span class="remark">| --> </span></em>and + <em><span class="remark"><--| Semantic differences between the 2| </span></em>POST or PUT + <em><span class="remark">|--> </span></em>it back, for example, where "small", "medium" and + "large" templates or pre-configured appliances are offered.</p><h3><a id="id36064889"/>Retrieve</h3><p>The simplest command is to retrieve a single resource by conducting a HTTP GET on its URL (which doubles as its identifier):</p><pre class="screen">GET /compute/b10fa926-41a6-4125-ae94-bfad2670ca87 HTTP/1.1 Host: example.com</pre><p>This will return <em><span class="remark">a HTTP 300 Multiple Choices response containing a list of available representations for the resource as well as a suggestion in the form of a HTTP Location: header of</span></em> the default rendering, which should be HTML (thereby allowing standard browsers to access the API directly). An arbitrary number of alternatives - may also be returned by way of HTTP Link: headers.</p><p>If you just need to know what representations are available you + may also be returned by way of HTTP Link: headers. <em><span class="remark"><--| this + requires 2 calls by default |--></span></em></p><p>If you just need to know what representations are available you should make a HEAD request instead of a GET - this will return the - metadata in the headers without the default rendering.</p><p>Some requests (such as searches) will need to return a collection of - resources. There are two options:</p><div class="glosslist"><dl><dt>Pass-by-reference</dt><dd><p>A plain text or HTML list of links is provided but each needs - to be retrieved separately, resulting in O(n+1) performance.</p></dd><dt>Pass-by-value</dt><dd><p>A wrapper format such as Atom is used to deliver [links to] + metadata in the headers without the default rendering.</p><p>Some requests, such as the collections returned using the search + extension, will need to return a collection of resources. There are two + concepts that are supported:</p><div class="glosslist"><dl><dt>Pass-by-reference:</dt><dd><p>A plain text or HTML list of links is provided but each needs + to be retrieved separately, resulting in O(n+1) performance.</p></dd><dt>Pass-by-value:</dt><dd><p>A wrapper format such as Atom is used to deliver [links to] the content as well as the metadata (e.g. links, associations, - cahching information, etc.), resulting in O(1) performance.</p></dd></dl></div><h3><a id="id36064863"/>Update</h3><p>Updating resources is trivial - simply GET the resource, modify it - as necessary and PUT it back where you found it.</p><h3><a id="id36064871"/>Delete</h3><p>Simply <code class="computeroutput">DELETE</code> the resource:</p><pre class="screen">DELETE /compute/b10fa926-41a6-4125-ae94-bfad2670ca87 HTTP/1.1 -Host: example.com</pre></div><div class="section" title="Sub-resource Collections"><div class="titlepage"><div><div><h2 class="title"><a id="id36064886"/>Sub-resource Collections</h2></div></div></div><p><em><span class="remark">(For want of a better name) </span></em></p><p>Each resource may expose collections for functions such as logging, + caching information, etc.), resulting in O(1) performance.</p></dd></dl></div><h3><a id="id36064957"/>Update</h3><p>Updating resources is trivial - simply GET the resource, modify it + as necessary and PUT <em><span class="remark"><--| What about someone using POST? + --></span></em> it back where you found it.</p><h3><a id="id36064969"/>Delete</h3><p>Simply <code class="computeroutput">DELETE</code> the resource:</p><pre class="screen">DELETE /compute/b10fa926-41a6-4125-ae94-bfad2670ca87 HTTP/1.1 +Host: example.com</pre></div><div class="section" title="Resource Child Collections"><div class="titlepage"><div><div><h2 class="title"><a id="id36064984"/>Resource Child Collections</h2></div></div></div><p>Each resource may expose collections for functions such as logging, auditing, change control, documentation and other operations (e.g. http://example.com/compute/123/log/456) in addition to any required by OCCI. As usual CRUD operations map to HTTP verbs (as above) and clients can either PUT entries directly if they know or will generate the identifiers, or POST them to the collection if this will be handled on the - server side (using POST Once Exactly (POE) to ensure idempotency).</p><h3><a id="id36064904"/>Requests</h3><p>Requests are used to trigger state changes and other operations such - as backups, snapshots, migrations and invasive reconfigurations (such as - storage resource resizing). Those that do not complete immediately - (returning HTTP 200 OK or similar) must be handled asynchronously - (returning HTTP 201 Accepted or similar).</p><pre class="screen">POST /compute/123/requests HTTP/1.1 + server side (using POST Once Exactly (POE) to ensure idempotency).</p><h3><a id="id36064998"/>Requests</h3><p><em><span class="remark"><--| This section must reference somewhere that lists + these </span></em>Requests <em><span class="remark">| --></span></em>are used to trigger state + changes and other operations such as backups, snapshots, migrations and + invasive reconfigurations (such as storage resource resizing). Those that + do not complete immediately (returning HTTP 200 OK or similar) must be + handled asynchronously (returning HTTP 201 Accepted or similar).</p><pre class="screen">POST /compute/123/requests HTTP/1.1 Host: example.com Content-Length: 35 Content-Type: application/x-www-form-urlencoded @@ -426,7 +434,7 @@ which are only handled daily at midnight) and may take some time to complete (for example a secure erase which requires multiple passes over the disk). Clients can poll for status periodically or use server push (or - a non-HTTP technology such as XMPP) to monitor for events.</p></div></div><div class="article" title="OCCI Frequently Asked Questions"><div class="titlepage"><div><div><h2 class="title"><a id="id36066287"/>OCCI Frequently Asked Questions</h2></div></div><hr/></div><div class="section" title="General"><div class="titlepage"><div><div><h2 class="title"><a id="id36066406"/>General</h2></div></div></div><div class="glosslist"><dl><dt>Who created the Open Cloud Computing Interface + a non-HTTP technology such as XMPP) to monitor for events.</p></div></div><div class="article" title="OCCI Frequently Asked Questions"><div class="titlepage"><div><div><h2 class="title"><a id="id36066411"/>OCCI Frequently Asked Questions</h2></div></div><hr/></div><div class="section" title="General"><div class="titlepage"><div><div><h2 class="title"><a id="id36066537"/>General</h2></div></div></div><div class="glosslist"><dl><dt>Who created the Open Cloud Computing Interface (OCCI)?</dt><dd><p>The Open Grid Forum (OGF)'s Open Cloud Computing Interface Working Group (OCCI-WG) created the Open Cloud Computing Interface (OCCI).</p></dd><dt>Who are the Open Cloud Computing Interface Working Group @@ -435,42 +443,50 @@ the chairs, and Sam Johnston (Australian Online Solutions) is the secretary.</p></dd><dt>Who else was involved?</dt><dd><p>Around 200 individuals representing over 100 companies were involved in the development of the Open Cloud Computing Interface - (OCCI).</p></dd></dl></div></div><div class="section" title="Use Cases"><div class="titlepage"><div><div><h2 class="title"><a id="id36066463"/>Use Cases</h2></div></div></div><div class="glosslist"><dl><dt>How were the use cases collected?</dt><dd><p>Use cases were solicited from the working group mailing list - as well as other external sources.</p></dd></dl></div></div><div class="section" title="Technical"><div class="titlepage"><div><div><h2 class="title"><a id="id36066488"/>Technical</h2></div></div></div><div class="glosslist"><dl><dt>Why didn't you invent your own XML + (OCCI).</p></dd></dl></div></div><div class="section" title="Use Cases"><div class="titlepage"><div><div><h2 class="title"><a id="id36066595"/>Use Cases</h2></div></div></div><div class="glosslist"><dl><dt>How were the use cases collected?</dt><dd><p>Use cases were solicited from the working group mailing list + as well as other external sources.</p></dd></dl></div></div><div class="section" title="Technical"><div class="titlepage"><div><div><h2 class="title"><a id="id36066620"/>Technical</h2></div></div></div><div class="glosslist"><dl><dt>Why didn't you invent your own XML representation?</dt><dd><p>See Tim Bray's Don’t Invent XML - Languages post.</p></dd></dl></div></div></div><div class="article" title="OCCI Core Specification"><div class="titlepage"><div><div><h2 class="title"><a id="id36068729"/>OCCI Core Specification</h2></div></div><hr/></div><div class="section" title="Introduction"><div class="titlepage"><div><div><h2 class="title"><a id="id36069560"/>Introduction</h2></div></div></div><p>The Open Cloud Computing Interface (OCCI) is an open protocol for - all cloud computing services. A RESTful interface, it deviates from the - underlying HyperText Transfer Protocol (HTTP) only where absolutely - necessary and can be described as a "Resource Oriented Architecture + Languages post.</p></dd></dl></div></div></div><div class="article" title="OCCI Core Specification & Models"><div class="titlepage"><div><div><h2 class="title"><a id="id36066417"/>OCCI Core Specification & Models</h2></div></div><hr/></div><div class="section" title="Introduction"><div class="titlepage"><div><div><h2 class="title"><a id="id36069859"/>Introduction</h2></div></div></div><p>The Open Cloud Computing Interface (OCCI) is an open protocol for + cloud computing services. It initially targets the infrastructure services + (IaaS) layer but its modular design which extends this OCCI Core + Specification allows for future targeting of the platform services (PaaS) + and application services (SaaS) layers on a future roadmap.</p><p>A Representational State Transfer (REST) protocol, it deviates from + the underlying HyperText Transfer Protocol (HTTP) only where absolutely + necessary and could be described as a "Resource Oriented Architecture (ROA)".<a class="xref" href="#core-rws" title="RESTful Web Services">RWS</a> Unlike other envelope-based protocols - which operate in-band, all existing HTTP features are available for - caching, proxying, gatewaying and other advanced functionality such as - partial GETs.</p><p>Each resource is identified by URL(s) and has one or more - representations which may include a hypertext (e.g. XHTML5) rendering for - direct end-user accessibility. As such OCCI can present both a machine - interface (using native resource renderings) and a user interface (using - HTML markup with forms and other web technologies such as - Javascript/Ajax). HTTP content negotiation is used to select between - alternative representations and metadata including associations between - resources is exposed via HTTP headers (e.g. the - <code class="computeroutput">Link:</code> and + such as Atom and SOAP (which describe complex XML-based structures for + data transferred within the HTTP payload, essentially duplicating HTTP's + built in header-based metadata functionality), OCCI provides a "clean + channel" over which any suitable format can travel without modification or + wrapping, using HTTP to its full extent in the way it was intended. OCCI + also uses various HTTP verbs in transactions rather than tunneling + everything over POST, as was the case with SOAP and the various WS-* + protocols. As such all existing HTTP features are available for caching, + proxying, gatewaying and other advanced functionality such as partial + GETs.</p><p>Each resource (i.e. a compute node) is identified by URL(s) and has + one or more native representations (i.e. Open Virtualisation Format or + OVF) as well as a generic XHTML5 rendering. The latter allows for direct + end-user accessibility with well-formed, embedded semantic web markup for + consumption by both human and machine clients. As such OCCI simultaneously + presents both a machine interface (using native resource renderings) and a + user interface (using HTML markup with forms and other web technologies + such as Javascript/Ajax) so as to satisfy all common use cases. HTTP + content negotiation is used to select between alternative representations + and metadata including associations between resources is exposed via HTTP + headers (e.g. the <code class="computeroutput">Link:</code> and <code class="computeroutput">Category:</code> headers).</p><p>In this way OCCI is not responsible for the representations themselves, rather it enables users to organise and group resources together to build arbitrarily complex systems of inter-related resources. It relies on existing standards for rendering and does not make any - recommendations of one standard format over any other.</p><div class="tip" title="Tip" style="margin-left: 0.5in; margin-right: 0.5in;"><h3 class="title">Tip</h3><p>This is the case for the World Wide Web today where many image, - video and other supporting formats co-exist. Browsers support a number - of the common formats and users choose the most appropriate for the - task.</p></div><div class="section" title="Example"><div class="titlepage"><div><div><h3 class="title"><a id="id36069607"/>Example</h3></div></div></div><pre class="screen">> GET /us-east/webapp/vm01 HTTP/1.1 -> User-Agent: occi-client/1.0 (linux) libcurl/7.19.4 OCCI/1.0 + recommendations of one standard format over any other, in the same way as + the Internet has many popular image formats.</p><div class="section" title="Example"><div class="titlepage"><div><div><h3 class="title"><a id="id36069910"/>Example</h3></div></div></div><pre class="screen">> GET /us-east/webapp/vm01 HTTP/1.1 > Host: cloud.example.com > Accept: */* > < HTTP/1.1 200 OK -< Date: Sat, 10 Oct 2009 12:56:51 GMT < Content-Type: application/ovf < Link: </us-east/webapp/vm01;start>; -< rel="http://purl.org/occi/action/start"; +< rel="http://purl.org/occi/action#start"; < title="Start" < Link: </us-east/webapp/build.pdf>; < rel="related"; @@ -478,27 +494,119 @@ < type="application/pdf" < Category: compute; < label="Compute Resource"; -< scheme="http://purl.org/occi/kind/" +< scheme="http://purl.org/occi/kind#" < Server: occi-server/1.0 (linux) OCCI/1.0 < Connection: close < < <?xml version="1.0" encoding="UTF-8"?> -< <Envelope xmlns:xsi="http://www.w3.org/2001/XMLSchema-instance" -< xmlns:ovf="http://schemas.dmtf.org/ovf/envelope/1" -< xmlns="http://schemas.dmtf.org/ovf/envelope/1" -< xml:lang="en-US"> -...</pre></div></div><div class="section" title="Basics"><div class="titlepage"><div><div><h2 class="title"><a id="id36069626"/>Basics</h2></div></div></div><div class="section" title="Entry point"><div class="titlepage"><div><div><h3 class="title"><a id="id36069631"/>Entry point</h3></div></div></div><p>The interface is defined by a single URL entry point which will - either be a <em class="glossterm">collection</em>, contain - <em class="glossterm">link</em>(s) to <em class="glossterm">collection</em>(s) - or both.</p></div><div class="section" title="Kinds, Actions & Attributes"><div class="titlepage"><div><div><h3 class="title"><a id="id36069653"/>Kinds, Actions & Attributes</h3></div></div></div><p>An interface exposes "kinds" which have "attributes" and on which - "actions" can be performed. The attributes are exposed as key-value - pairs and applicable actions as links, following the REST hypertext - constraint (whereby state transitions are defined - <em class="glossterm">in-band</em> rather than via rules).</p></div><div class="section" title="HTTP Verbs"><div class="titlepage"><div><div><h3 class="title"><a id="id36069669"/>HTTP Verbs</h3></div></div></div><p>Create, Retrieve, Update and Delete (CRUD) operations map to the +...</pre></div></div><div class="section" title="Essentials"><div class="titlepage"><div><div><h2 class="title"><a id="id36069926"/>Essentials</h2></div></div></div><div class="section" title="Connection"><div class="titlepage"><div><div><h3 class="title"><a id="id36069932"/>Connection</h3></div></div></div><div class="section" title="Authentication"><div class="titlepage"><div><div><h4 class="title"><a id="id36069938"/>Authentication</h4></div></div></div><p>Servers <span class="emphasis"><em>may</em></span> require that requests be + authenticated using standard HTTP-based authentication mechanisms + (including OAuth).<a class="xref" href="#core-oauth" title="OAuth">OAuth</a> They indicate this + requirement by returning <code class="code">HTTP 401</code> with a + <code class="code">WWW-Authenticate</code> header and a suitable challenge (e.g. + <code class="code">Basic</code>, <code class="code">Digest</code>, <code class="code">OAuth</code>). </p><pre class="screen">> GET / HTTP/1.1 +> Host: cloud.example.com +> +< HTTP/1.1 401 Unauthorized +< WWW-Authenticate: OAuth realm="http://sp.example.com/"</pre><p>The client then includes appropriate <code class="code">Authorization</code> + headers in its responses:<a class="xref" href="#core-rfc2617" title="RFC 2617 - HTTP Authentication: Basic and Digest Access Authentication">RFC2617</a></p><pre class="screen">> GET / HTTP/1.1 +> Authorization: OAuth realm="http://sp.example.com/", +> oauth_consumer_key="0685bd9184jfhq22", +> oauth_token="ad180jjd733klru7", +> oauth_signature_method="HMAC-SHA1", +> oauth_signature="wOJIO9A2W5mFwDgiDvZbTSMK%2FPY%3D", +> oauth_timestamp="137131200", +> oauth_nonce="4572616e48616d6d65724c61686176", +> oauth_version="1.0"</pre></div><div class="section" title="Cookies"><div class="titlepage"><div><div><h4 class="title"><a id="id36069997"/>Cookies</h4></div></div></div><p>Servers <span class="emphasis"><em>may</em></span> set and clients + <span class="emphasis"><em>may</em></span> accept <em class="glossterm">cookies</em> in + order to maintain authentication state between requests:<a class="xref" href="#core-rfc2109" title="RFC 2109 - HTTP State Management Mechanism">RFC2109</a></p><pre class="screen">Set-Cookie: session=4732518c5fe6dbeb8429cdda11d65c3d; domain=.example.com; path=/</pre><div class="warning" title="Warning" style="margin-left: 0.5in; margin-right: 0.5in;"><h3 class="title">Warning</h3><p>Such sessions <span class="emphasis"><em>should not</em></span> be used for + other purposes (such as server-side state) in line with RESTful + principles.</p></div></div><div class="section" title="Versioning"><div class="titlepage"><div><div><h4 class="title"><a id="id36070037"/>Versioning</h4></div></div></div><p>Servers and clients <span class="emphasis"><em>should</em></span> indicate the + latest version of OCCI they support (e.g. + <code class="computeroutput">1.0</code>) by way of the + <code class="computeroutput">Server:</code> and + <code class="computeroutput">User-Agent:</code> headers respectively, + using the token <span class="quote">“<span class="quote"><code class="computeroutput">OCCI</code></span>”</span> + (e.g. <span class="quote">“<span class="quote"><code class="computeroutput">OCCI/1.0</code></span>”</span>). If + none is provided the latest (highest supported version number) + available version offered by the server <span class="emphasis"><em>should</em></span> be + used:</p><pre class="screen">> GET / HTTP/1.1 +> Host: cloud.example.com +> User-Agent: occi-client/1.0 (linux) libcurl/7.19.4 OCCI/1.0 +> +< HTTP/1.1 200 OK +< Server: Apache/2.2.13 (Unix) OCCI/1.0</pre></div></div><div class="section" title="Addressing"><div class="titlepage"><div><div><h3 class="title"><a id="id36070082"/>Addressing</h3></div></div></div><p>A single entry point is defined by a URL (e.g. + <code class="uri">http://cloud.example.com/</code>) which may be a collection of + resources or some other page as defined by the implementor (e.g. a + descriptive web page). Therefore OCCI is fully compatible with any + existing web presence such as a marketing site or landing page.</p><p>All resources <span class="emphasis"><em>must</em></span> be addressible by URLs + (whose structure is opaque and at the discretion of the implementor) and + discoverable via search and/or link traversal from the entry point. + Clients <span class="emphasis"><em>should not</em></span> rely on "rules" to construct + URLs, rather learning them from URLs previously retrieved, in line with + RESTful principles:</p><pre class="screen">> GET /-/compute/ HTTP/1.1 +> Accept: text/uri-list +> +< HTTP/1.1 200 OK +< Content-type: text/uri-list +< +< /us-east/new-york/node17 +< /us-west/san-francisco/node43 +< /europe/paris/node38</pre></div><div class="section" title="Bootstrapping"><div class="titlepage"><div><div><h3 class="title"><a id="id36070116"/>Bootstrapping</h3></div></div></div><p>Clients will typically conduct a + <code class="computeroutput">GET</code> or + <code class="computeroutput">HEAD</code> request on the root + (<span class="quote">“<span class="quote"><code class="uri">/</code></span>”</span>) and discover the category search + interface, from which they can learn the supported categories/kinds and + retrieve some or all of them. If they know the URL for the resource they + wish to interact with (e.g. scripts & cron jobs) then they can + bypass the discovery process and manipulate it directly.</p><div class="example"><a id="id36070140"/><p class="title"><b>Example 1. Example bootstrap</b></p><div class="example-contents"><p>Retrieve a collection of desired resources (having already + discovered the category search URL and available categories):</p><pre class="screen"># detect category search interface +> GET / HTTP/1.1 +> Host: cloud.example.com +> +< HTTP/1.1 200 OK +< Content-type: text/html +< Link: </-/>; rel="search"; title="Category Search" +< +< <html> +< <head> +< <...> +< +# detect categories +> GET /-/ HTTP/1.1 +> +< HTTP/1.1 200 OK +< Content-length: 0 +< +< Category: compute; label="Compute Resource"; scheme="http://purl.org/occi/kind#" +< Category: network; label="Network Resource"; scheme="http://purl.org/occi/kind#" +< Category: storage; label="Storage Resource"; scheme="http://purl.org/occi/kind#" +< Category: us-east; label="US East Coast"; scheme="http://example.com/locations" +< Category: us-west; label="US West Coast"; scheme="http://example.com/locations" +< Category: demo; label="My Customer Demo"; scheme="http://example.com/~user/" +< +# retrieve category +> GET /-/compute HTTP/1.1 +> +> HTTP/1.1 200 OK +> Content-type: text/uri-list +> +> /node1 +> /node2 +> +# retrieve resource +> GET /node1 HTTP/1.1 +> +> HTTP/1.1 200 OK +> Content-type: application/ovf +> <...></pre></div></div><br class="example-break"/></div></div><div class="section" title="Operations"><div class="titlepage"><div><div><h2 class="title"><a id="id36070165"/>Operations</h2></div></div></div><div class="section" title="HTTP Verbs"><div class="titlepage"><div><div><h3 class="title"><a id="id36070171"/>HTTP Verbs</h3></div></div></div><p>Create, Retrieve, Update and Delete (CRUD) operations map to the POST, GET, PUT and DELETE HTTP verbs respectively. HEAD and OPTIONS verbs may be used to retrieve metadata and valid operations without the entity body to improve performance. WebDAV definitions are used for - MKCOL, MOVE and COPY.</p><div class="glosslist"><dl><dt>POST (Create)</dt><dd><p><span class="quote">“<span class="quote">The POST method is used to request that the origin + MKCOL, MOVE and COPY.</p><div class="warning" title="Warning" style="margin-left: 0.5in; margin-right: 0.5in;"><h3 class="title">Warning</h3><p>Some providers may implement a subset of these operations, and + those available to you for a given resource (if any) may depend on + security policy. Be prepared to handle exceptions if you attempt to + call operations that are not available to you.</p></div><div class="glosslist"><dl><dt>POST (Create)</dt><dd><p><span class="quote">“<span class="quote">The POST method is used to request that the origin server accept the entity enclosed in the request as a new subordinate of the resource identified by the Request-URI in the Request-Line.</span>”</span><a class="xref" href="#core-rfc2616" title="RFC 2616 - Hypertext Transfer Protocol -- HTTP/1.1">RFC2616</a></p><p>POSTing a representation (e.g. OVF) to a collection (e.g. @@ -512,11 +620,16 @@ "406 Not Acceptable" will be returned.</p></dd><dt>PUT (Create or Update)</dt><dd><p><span class="quote">“<span class="quote">The PUT method requests that the enclosed entity be stored under the supplied Request-URI.</span>”</span><a class="xref" href="#core-rfc2616" title="RFC 2616 - Hypertext Transfer Protocol -- HTTP/1.1">RFC2616</a></p><p>PUTting a representation (e.g. OVF) to a URL (e.g. /compute/123) will result in the resource being created or - updated. The URL is known or selected by the client (in which case - UUIDs should be used), in contrast to POSTs where the URL is - selected by the server.</p></dd><dt>DELETE (Delete)</dt><dd><p><span class="quote">“<span class="quote">The DELETE method requests that the origin server + updated. The URL is known or selected by the client, in contrast + to POSTs where the URL is selected by the server.</p></dd><dt>DELETE (Delete)</dt><dd><p><span class="quote">“<span class="quote">The DELETE method requests that the origin server delete the resource identified by the Request-URI.</span>”</span><a class="xref" href="#core-rfc2616" title="RFC 2616 - Hypertext Transfer Protocol -- HTTP/1.1">RFC2616</a></p><p>DELETE results in the deletion of the resource (and - everything "under" it, as appropriate).</p></dd></dl></div><p>Additionally the following HTTP methods are used:</p><div class="glosslist"><dl><dt>COPY (Duplicate)</dt><dd><p><span class="quote">“<span class="quote">The COPY method creates a duplicate of the source + everything "under" it, as appropriate).</p></dd></dl></div><div class="tip" title="Tip" style="margin-left: 0.5in; margin-right: 0.5in;"><h3 class="title">Tip</h3><p>It is possible to instruct the server to create a resource based + on a default configuration (without requiring client support) by doing + an empty POST/PUT, specifying <span class="quote">“<span class="quote"><code class="computeroutput">Content-type: + application/occi</code></span>”</span> (such that the web server + knows where to route the request) and specifying the appropriate + <em class="parameter"><code>kind</code></em> category (such that OCCI knows what to + create).</p></div><p>Additionally the following HTTP methods are used:</p><div class="glosslist"><dl><dt>COPY (Duplicate)</dt><dd><p><span class="quote">“<span class="quote">The COPY method creates a duplicate of the source resource identified by the Request-URI, in the destination resource identified by the URI in the Destination header.</span>”</span><a class="xref" href="#core-rfc4918" title="RFC 4918 - HTTP Extensions for Web Distributed Authoring and Versioning (WebDAV)">RFC4918</a></p></dd><dt>HEAD (Retrieve - Metadata Only)</dt><dd><p><span class="quote">“<span class="quote">The HEAD method is identical to GET except that the @@ -528,63 +641,28 @@ all three actions are performed in a single operation.</span>”</span><a class="xref" href="#core-rfc4918" title="RFC 4918 - HTTP Extensions for Web Distributed Authoring and Versioning (WebDAV)">RFC4918</a></p></dd><dt>OPTIONS</dt><dd><p><span class="quote">“<span class="quote">The OPTIONS method represents a request for information about the communication options available on the - request/response chain identified by the Request-URI.</span>”</span><a class="xref" href="#core-rfc2616" title="RFC 2616 - Hypertext Transfer Protocol -- HTTP/1.1">RFC2616</a></p></dd></dl></div></div></div><div class="section" title="Connection"><div class="titlepage"><div><div><h2 class="title"><a id="id36069890"/>Connection</h2></div></div></div><div class="section" title="Authentication"><div class="titlepage"><div><div><h3 class="title"><a id="id36069896"/>Authentication</h3></div></div></div><p>Servers <span class="emphasis"><em>may</em></span> require that requests be - authenticated using standard HTTP-based authentication mechanisms - (including OAuth).<a class="xref" href="#core-oauth" title="OAuth">OAuth</a> They indicate this - requirement by returning <code class="code">HTTP 401</code> with a - <code class="code">WWW-Authenticate</code> header and a suitable challenge (e.g. - <code class="code">Basic</code>, <code class="code">Digest</code>, <code class="code">OAuth</code>). The client - then includes appropriate <code class="code">Authorization</code> headers in its - responses.<a class="xref" href="#core-rfc2617" title="RFC 2617 - HTTP Authentication: Basic and Digest Access Authentication">RFC2617</a></p><p>Servers <span class="emphasis"><em>may</em></span> set and clients - <span class="emphasis"><em>may</em></span> accept <em class="glossterm">cookies</em> in order - to maintain authentication state between requests. Such sessions - <span class="emphasis"><em>should not</em></span> be used for other purposes (such as - server-side state) in line with RESTful principles.<a class="xref" href="#core-rfc2109" title="RFC 2109 - HTTP State Management Mechanism">RFC2109</a></p></div><div class="section" title="Versioning"><div class="titlepage"><div><div><h3 class="title"><a id="id36069962"/>Versioning</h3></div></div></div><p>Servers and clients <span class="emphasis"><em>should</em></span> indicate the - latest version of OCCI they support (e.g. - <code class="computeroutput">1.0</code>) by way of the - <code class="computeroutput">Server:</code> and - <code class="computeroutput">User-Agent:</code> headers respectively, using - the token <span class="quote">“<span class="quote"><code class="computeroutput">OCCI</code></span>”</span> (e.g. - <span class="quote">“<span class="quote"><code class="computeroutput">OCCI/1.0</code></span>”</span>). If none is - provided the latest available version <span class="emphasis"><em>shall</em></span> be - used.</p></div></div><div class="section" title="Model"><div class="titlepage"><div><div><h2 class="title"><a id="id36070001"/>Model</h2></div></div></div><p>The model defines the objects themselves without regard to how they - interrelate.</p><div class="section" title="Kinds"><div class="titlepage"><div><div><h3 class="title"><a id="id36070011"/>Kinds</h3></div></div></div><p>Each category of resources distinguished by some common - characteristic or quality is called a <em class="glossterm">kind</em> (e.g. - <code class="computeroutput">compute</code>, - <code class="computeroutput">network</code>, - <code class="computeroutput">storage</code>, - <code class="computeroutput">queue</code>, - <code class="computeroutput">application</code>, - <code class="computeroutput">contact</code>).</p><p>Kinds defined by this standard live in the - <code class="uri">http://purl.org/occi/kind/</code> namespace but anyone can define a - new kind by allocating a URI they control.</p><div class="warning" title="Warning" style="margin-left: 0.5in; margin-right: 0.5in;"><h3 class="title">Warning</h3><p>Defining your own kinds can lead to interoperability problems - and should be a last resort reserved for unique functionality. A - simple peer review process is available for extending the registries - which should be used where possible.</p></div><p>Each resource <span class="emphasis"><em>must</em></span> specify a kind by way of a - <em class="glossterm">category</em> within the <em class="glossterm">scheme</em> - <span class="quote">“<span class="quote"><code class="uri">http://purl.org/occi/kind/</code></span>”</span>.</p><div class="tip" title="Tip" style="margin-left: 0.5in; margin-right: 0.5in;"><h3 class="title">Tip</h3><p>The word <em class="glossterm">type</em> is not used in this context - in order to avoid confusion with Internet media types.</p></div></div><div class="section" title="Attributes"><div class="titlepage"><div><div><h3 class="title"><a id="id36070094"/>Attributes</h3></div></div></div><p>An <em class="glossterm">attribute</em> is a specification that - defines a property of an object. It is expressed in the form of - key-value pairs. Attributes are divided into namespaces which are - separated by the dot character (<span class="quote">“<span class="quote">.</span>”</span>).</p><div class="tip" title="Tip" style="margin-left: 0.5in; margin-right: 0.5in;"><h3 class="title">Tip</h3><p>This scalable approach was derived from the Mozilla Firefox - <code class="uri">about:config</code> page.</p></div><p>Attributes defined by this standard reside under the - <code class="computeroutput">occi</code> namespace (e.g. - "<code class="computeroutput">occi.abc</code>") but anyone can define a new - attribute by allocating a unique namespace based on their reversed - Internet domain (e.g. - <span class="quote">“<span class="quote"><code class="computeroutput">com.cisco.cdp</code></span>”</span>).</p><div class="warning" title="Warning" style="margin-left: 0.5in; margin-right: 0.5in;"><h3 class="title">Warning</h3><p>Defining your own attributes can lead to interoperability - problems and should be a last resort reserved for unique - functionality. A simple peer review process is available for extending - the registries which should be used where possible.</p></div><div class="section" title="Registry Entries"><div class="titlepage"><div><div><h4 class="title"><a id="id36070148"/>Registry Entries</h4></div></div></div><div class="table"><a id="id36070154"/><p class="title"><b>Table 1. Core Attributes</b></p><div class="table-contents"><table summary="Core Attributes" border="1"><colgroup><col style="text-align: center"/><col/><col/><col/></colgroup><thead><tr><th style="text-align: left">Attribute</th><th>Description</th><th>Type</th><th>Example</th></tr></thead><tbody><tr><td style="text-align: left"><code class="computeroutput">occi.id</code></td><td>Immutable identifier for the resource</td><td>URI</td><td><code class="uri">urn:uuid:d0e9f0d0-f62d-4f28-bc90-23b0bd871770</code></td></tr><tr><td style="text-align: left"><code class="computeroutput">occi.title</code></td><td>Display name for the resource</td><td>String</td><td><code class="computeroutput">Compute Resource - #123</code></td></tr><tr><td style="text-align: left"><code class="computeroutput">occi.summary</code></td><td>Description of the resource</td><td>String</td><td><code class="computeroutput">A virtual compute - resource</code></td></tr><tr><td style="text-align: left"><code class="computeroutput">occi.version</code></td><td>Specification version</td><td>Float</td><td><code class="computeroutput">1.0</code></td></tr></tbody></table></div></div><br class="table-break"/></div></div><div class="section" title="Actions"><div class="titlepage"><div><div><h3 class="title"><a id="id36070289"/>Actions</h3></div></div></div><p>An <em class="glossterm">action</em> is some process that can be - carried out on one or more <em class="glossterm">resource</em>s.</p><p>Each available <em class="glossterm">action</em> for a given + request/response chain identified by the Request-URI.</span>”</span><a class="xref" href="#core-rfc2616" title="RFC 2616 - Hypertext Transfer Protocol -- HTTP/1.1">RFC2616</a></p></dd></dl></div><div class="tip" title="Tip" style="margin-left: 0.5in; margin-right: 0.5in;"><h3 class="title">Tip</h3><p>Implementors may offer full WebDAV support in order to allow + clients to enumerate the entire tree, interact with the resources via + standard file managers (e.g. Windows Explorer, Mac OS X Finder), + etc.</p></div></div><div class="section" title="Actions"><div class="titlepage"><div><div><h3 class="title"><a id="id36070426"/>Actions</h3></div></div></div><p>An <em class="glossterm">action</em> is some process that can be + carried out on one or more <em class="glossterm">resource</em>s, which may + result in a state change and/or the creation of new resource(s).</p><div class="tip" title="Tip" style="margin-left: 0.5in; margin-right: 0.5in;"><h3 class="title">Tip</h3><p>Use common sense to decide what functionality should be exposed + by way of actions and consult the list of existing actions and verbs + before creating your own. For example it does not make sense to resize + a storage resource by setting the <span class="quote">“<span class="quote">size</span>”</span> attribute + (indeed there may not be space available or the filesystem may not + support resizing and in any case the operation will take some time), + nor to start a machine by changing the state from + <span class="quote">“<span class="quote">stopped</span>”</span> to <span class="quote">“<span class="quote">running</span>”</span>.</p></div><p>Each available <em class="glossterm">action</em> for a given <em class="glossterm">resource</em> is indicated via a - <em class="glossterm">link</em> with the - <code class="computeroutput">action</code> class.</p><pre class="screen">Link: </us-east/webapp/vm01;start>; - rel="http://purl.org/occi/action/start"; + <em class="glossterm">link</em> with <em class="parameter"><code>class</code></em> extension + set to <span class="quote">“<span class="quote"><em class="parameter"><code>action</code></em></span>”</span> (such that clients + can identify actions, including those from third-parties, without + deriving meaning from the <em class="parameter"><code>rel</code></em> URI).</p><pre class="screen">Link: </us-east/webapp/vm01;start>; + rel="http://purl.org/occi/action#start"; + class="action"; title="Start"</pre><p>Actions defined by this standard reside under the - <code class="uri">http://purl.org/occi/action/</code> namespace but anyone can define + <code class="uri">http://purl.org/occi/action#</code> namespace but anyone can define a new action by allocating a URI they control.</p><div class="warning" title="Warning" style="margin-left: 0.5in; margin-right: 0.5in;"><h3 class="title">Warning</h3><p>Defining your own actions can lead to interoperability problems and should be a last resort reserved for unique functionality. A simple peer review process is available for extending the registries @@ -592,12 +670,12 @@ depending on the action requested (e.g. <code class="computeroutput">resize</code>), parameters <span class="emphasis"><em>may</em></span> be provided using HTML forms (e.g. - <code class="computeroutput">application/x-www-form-encoded</code>). In the - case of HTML-based renderings the actions can therefore be actual HTML - forms.</p><div class="tip" title="Tip" style="margin-left: 0.5in; margin-right: 0.5in;"><h3 class="title">Tip</h3><p>Some resources can be interacted with but not rendered due to + <code class="computeroutput">application/x-www-form-urlencoded</code>). In + the case of HTML-based renderings the actions can therefore be actual + HTML forms.</p><div class="tip" title="Tip" style="margin-left: 0.5in; margin-right: 0.5in;"><h3 class="title">Tip</h3><p>Some resources can be interacted with but not rendered due to the nature of the resource or prevailing security policies (for example, an operator may be able to backup a machine without knowing - anything about it).</p></div><div class="section" title="Asynchronous Actions"><div class="titlepage"><div><div><h4 class="title"><a id="id36070373"/>Asynchronous Actions</h4></div></div></div><p>Synchronous actions <span class="emphasis"><em>may</em></span> return + anything about it).</p></div><div class="section" title="Asynchronous Actions"><div class="titlepage"><div><div><h4 class="title"><a id="id36070541"/>Asynchronous Actions</h4></div></div></div><p>Synchronous actions <span class="emphasis"><em>may</em></span> return <code class="computeroutput">200 OK</code> on successful completion or <code class="computeroutput">201 Created</code> with a <code class="computeroutput">Location:</code> header indicating a new @@ -608,16 +686,55 @@ <code class="computeroutput">Location:</code> header indicating a new resource where status and other pertinent information can be obtained.</p><div class="tip" title="Tip" style="margin-left: 0.5in; margin-right: 0.5in;"><h3 class="title">Tip</h3><p>Don't keep clients waiting - if you're not sure to return - immediately then give them a resource they can monitor.</p></div></div><div class="section" title="Advanced Actions"><div class="titlepage"><div><div><h4 class="title"><a id="id36070433"/>Advanced Actions</h4></div></div></div><p>The specific parameters required and allowable values for them + immediately then give them a resource they can monitor. For example + by responding with an 202 Accepted return code and include a + location: header, as described.</p></div></div><div class="section" title="Advanced Actions"><div class="titlepage"><div><div><h4 class="title"><a id="id36070602"/>Advanced Actions</h4></div></div></div><p>The specific parameters required and allowable values for them depend on the action and for advanced actions <span class="emphasis"><em>may</em></span> require sending of custom <em class="glossterm">content type</em>s rather than - <code class="computeroutput">application/x-www-form-encoded</code>.</p></div></div></div><div class="section" title="Meta-model"><div class="titlepage"><div><div><h2 class="title"><a id="id36070458"/>Meta-model</h2></div></div></div><p>The meta-model defines how objects interrelate.</p><div class="section" title="Categories"><div class="titlepage"><div><div><h3 class="title"><a id="id36070467"/>Categories</h3></div></div></div><p><em class="glossterm">Category</em> information allows for flexible + <code class="computeroutput">application/x-www-form-encoded</code>.</p></div><div class="section" title="State Machines"><div class="titlepage"><div><div><h4 class="title"><a id="id36070625"/>State Machines</h4></div></div></div><p>State machines are maintained on the server side and possible + transitions are advertised to the client by way of action links. The + links offered to a given client may depend on the resource, its + current state, security policy, etc.</p><div class="tip" title="Tip" style="margin-left: 0.5in; margin-right: 0.5in;"><h3 class="title">Tip</h3><p>Many state transitions will not be effected immediately so be + prepared to handle asynchronous responses.</p></div></div></div></div><div class="section" title="Model"><div class="titlepage"><div><div><h2 class="title"><a id="id36070647"/>Model</h2></div></div></div><p>The model defines the objects and how they interrelate. An interface + exposes "kinds" which have "attributes" and on which "actions" can be + performed. The attributes are exposed as key-value pairs and applicable + actions as links, following the REST hypertext constraint (whereby state + transitions are defined <em class="glossterm">in-band</em> rather than via + rules).</p><div class="section" title="Kinds"><div class="titlepage"><div><div><h3 class="title"><a id="id36070663"/>Kinds</h3></div></div></div><p>Each category of resources distinguished by some common + characteristic or quality is called a <em class="glossterm">kind</em> (e.g. + <code class="computeroutput">compute</code>, + <code class="computeroutput">network</code>, + <code class="computeroutput">storage</code>, + <code class="computeroutput">queue</code>, + <code class="computeroutput">application</code>, + <code class="computeroutput">contact</code>).</p><p>Kinds defined by this standard live in the + <code class="uri">http://purl.org/occi/kind/</code> namespace but anyone can define a + new kind by using a URI they control as the term.</p><div class="warning" title="Warning" style="margin-left: 0.5in; margin-right: 0.5in;"><h3 class="title">Warning</h3><p>Defining your own kinds can lead to interoperability problems + and should be a last resort reserved for unique functionality. A + simple peer review process is available for extending the registries + which should be used where possible.</p></div><p>Each resource <span class="emphasis"><em>must</em></span> specify a kind by way of a + <em class="glossterm">category</em> within the <em class="glossterm">scheme</em> + <span class="quote">“<span class="quote"><code class="uri">http://purl.org/occi/kind#</code></span>”</span>.</p><div class="tip" title="Tip" style="margin-left: 0.5in; margin-right: 0.5in;"><h3 class="title">Tip</h3><p>The word <em class="glossterm">type</em> is not used in this context + in order to avoid confusion with Internet media types.</p></div><div class="section" title="Attributes"><div class="titlepage"><div><div><h4 class="title"><a id="id36070744"/>Attributes</h4></div></div></div><p>An <em class="glossterm">attribute</em> is a specification that + defines a property of an object. It is expressed in the form of + key-value pairs. Attributes are divided into namespaces which are + separated by the dot character (<span class="quote">“<span class="quote">.</span>”</span>).</p><div class="tip" title="Tip" style="margin-left: 0.5in; margin-right: 0.5in;"><h3 class="title">Tip</h3><p>This scalable approach was derived from the Mozilla Firefox + <code class="uri">about:config</code> page.</p></div><p>Attributes defined by this standard reside at the root but + anyone can define a new attribute by allocating a unique namespace + based on their reversed Internet domain (e.g. + <span class="quote">“<span class="quote"><code class="computeroutput">com.example.attribute</code></span>”</span>).</p><div class="warning" title="Warning" style="margin-left: 0.5in; margin-right: 0.5in;"><h3 class="title">Warning</h3><p>Defining your own attributes can lead to interoperability + problems and should be a last resort reserved for unique + functionality. A simple peer review process is available for + extending the registries which should be used where possible.</p></div><div class="section" title="Registry Entries"><div class="titlepage"><div><div><h5 class="title"><a id="id36070792"/>Registry Entries</h5></div></div></div><div class="table"><a id="id36070798"/><p class="title"><b>Table 1. Core Attributes</b></p><div class="table-contents"><table summary="Core Attributes" border="1"><colgroup><col/><col/><col/><col/></colgroup><thead><tr><th style="text-align: left">Attribute</th><th>Description</th><th>Type</th><th>Example</th></tr></thead><tbody><tr><td style="text-align: left"><code class="computeroutput">id</code></td><td>Immutable, unique identifier for the resource</td><td>URI</td><td><code class="uri">urn:uuid:d0e9f0d0-f62d-4f28-bc90-23b0bd871770</code> + or <code class="uri">urn:aws:ami-123456</code></td></tr><tr><td style="text-align: left"><code class="computeroutput">title</code></td><td>Display name for the resource</td><td>String</td><td><code class="computeroutput">Compute Resource + #123</code></td></tr><tr><td style="text-align: left"><code class="computeroutput">summary</code></td><td>Description of the resource</td><td>String</td><td><code class="computeroutput">A virtual compute + resource</code></td></tr></tbody></table></div></div><br class="table-break"/></div></div></div><div class="section" title="Categories"><div class="titlepage"><div><div><h3 class="title"><a id="categories"/>Categories</h3></div></div></div><p><em class="glossterm">Category</em> information allows for flexible organisation of resources into one or more vocabularies (each of which - is referred to as a <em class="glossterm">scheme</em>).</p><p>The meta-model was derived from Atom, consisting of three + is referred to as a <em class="glossterm">scheme</em>).</p><p>The category model was derived from Atom and consists of three attributes:</p><div class="glosslist"><dl><dt>term</dt><dd><p>The term itself (e.g. <span class="quote">“<span class="quote"><code class="computeroutput">compute</code></span>”</span>)</p></dd><dt>scheme (optional)</dt><dd><p>The vocabulary (e.g. - <span class="quote">“<span class="quote"><code class="computeroutput">http://purl.org/occi/kind/</code></span>”</span>)</p></dd><dt>label (optional)</dt><dd><p>A human-friendly display name for the term (e.g. + <span class="quote">“<span class="quote"><code class="computeroutput">http://purl.org/occi/kind#</code></span>”</span>)</p></dd><dt>label (optional)</dt><dd><p>A human-friendly display name for the term (e.g. <span class="quote">“<span class="quote"><code class="computeroutput">Compute Resource</code></span>”</span>)</p></dd></dl></div><p>Category schemes and/or terms defined by this standard reside throughout the <code class="uri">http://purl.org/occi/</code> namespace but anyone can @@ -629,37 +746,64 @@ <code class="computeroutput">US-West</code>, <code class="computeroutput">Europe</code>), operating systems (e.g. <code class="computeroutput">Windows</code>, - <code class="computeroutput">Linux</code>) and patch levels (e.g.</p></div><div class="section" title="Examples"><div class="titlepage"><div><div><h4 class="title"><a id="id36070583"/>Examples</h4></div></div></div><pre class="screen">Category: compute; + <code class="computeroutput">Linux</code>) and patch levels (e.g.</p></div><div class="example"><a id="id36071201"/><p class="title"><b>Example 2. Category examples</b></p><div class="example-contents"><p>OCCI kinds are represented by a category:</p><pre class="screen">Category: compute; label="Compute Resource"; - scheme="http://purl.org/occi/kind/"</pre></div><div class="section" title="Querying"><div class="titlepage"><div><div><h4 class="title"><a id="id36070594"/>Querying</h4></div></div></div><p class="remark"><i><span class="remark">TODO: Pull query interface from GData: - http://code.google.com/apis/gdata/docs/2.0/reference.html#Queries</span></i></p></div><div class="section" title="Registry Entries"><div class="titlepage"><div><div><h4 class="title"><a id="id36070605"/>Registry Entries</h4></div></div></div><div class="table"><a id="id36070611"/><p class="title"><b>Table 2. Core Category Schemes</b></p><div class="table-contents"><table summary="Core Category Schemes" border="1"><colgroup><col style="text-align: center"/><col/></colgroup><thead><tr><th style="text-align: left">Scheme</th><th>Description</th></tr></thead><tbody><tr><td style="text-align: left"><code class="computeroutput">http://purl.org/occi/kind/</code></td><td>OCCI Kinds</td></tr></tbody></table></div></div><br class="table-break"/></div></div><div class="section" title="Collections"><div class="titlepage"><div><div><h3 class="title"><a id="id36070664"/>Collections</h3></div></div></div><p>Where an operation could return multiple resources (e.g. + scheme="http://purl.org/occi/kind#"</pre><p>Implementors and users can also define their own vocabularies by + defining schemes:</p><pre class="screen">Category: cluster1; + label="Cluster #1"; + scheme="http://example.com/clusters#"</pre></div></div><br class="example-break"/><div class="section" title="Querying"><div class="titlepage"><div><div><h4 class="title"><a id="id36071224"/>Querying</h4></div></div></div><p>The category query interface can be accessed by constructing an + URL with the desired categories added to the path. Categories can be + negated by prefixing with <span class="quote">“<span class="quote">-</span>”</span> and schemes may be + specified with braces.</p><div class="example"><a id="id36071238"/><p class="title"><b>Example 3. Example category query</b></p><div class="example-contents"><p>Locate the category search root (which + <span class="emphasis"><em>should</em></span> be <code class="uri">/-/</code>):</p><pre class="screen">> HEAD / HTTP/1.1 +> +< HTTP/1.1 200 OK +< Link: </-/>; rel="search"; title="Category Search"</pre><p>Discover the available categories (which will all be returned + in the same format as they appear in the HTTP headers):</p><pre class="screen">> GET /-/ HTTP/1.1 +> Accept: */* +> +< HTTP/1.1 200 OK +< Content-type: application/occi +< +< Category: compute; label="Compute Resource"; scheme="http://purl.org/occi/kind#" +< Category: network; label="Network Resource"; scheme="http://purl.org/occi/kind#" +< Category: storage; label="Storage Resource"; scheme="http://purl.org/occi/kind#" +< Category: us-east; label="US East Coast"; scheme="http://example.com/locations" +< Category: us-west; label="US West Coast"; scheme="http://example.com/locations" +< Category: demo; label="My Customer Demo"; scheme="http://example.com/~user/"</pre><p>Query the category search interface for the desired + category(s):</p><pre class="screen">> GET /-/compute/us-west HTTP/1.1 +> Accept: text/uri-list +> +< HTTP/1.1 200 OK +< Content-type: text/uri-list +< +< /vm01 +< /webapp/web01 +< /webapp/web02 +< /webapp/db01</pre></div></div><br class="example-break"/></div><div class="section" title="Registry Entries"><div class="titlepage"><div><div><h4 class="title"><a id="id36071283"/>Registry Entries</h4></div></div></div><div class="table"><a id="id36071289"/><p class="title"><b>Table 2. Core Category Schemes</b></p><div class="table-contents"><table summary="Core Category Schemes" border="1"><colgroup><col style="text-align: center"/><col/><col/></colgroup><thead><tr><th style="text-align: left">Scheme</th><th>Description</th><th>Example</th></tr></thead><tbody><tr><td style="text-align: left"><code class="computeroutput">http://purl.org/occi/kind#</code></td><td>OCCI Kinds</td><td><code class="computeroutput">compute</code></td></tr><tr><td style="text-align: left"><code class="computeroutput">http://purl.org/occi/category#countries</code></td><td>ISO Country Codes</td><td><code class="computeroutput">us</code></td></tr><tr><td style="text-align: left"><code class="computeroutput">http://purl.org/occi/category#us-states</code></td><td>US States</td><td><code class="computeroutput">ca</code></td></tr><tr><td style="text-align: left"><code class="computeroutput">http://purl.org/occi/category#operating-systems</code></td><td>Operating Systems</td><td><code class="computeroutput">linux</code></td></tr><tr><td style="text-align: left"><code class="computeroutput">http://purl.org/occi/category#regulations</code></td><td>Regulation compliance</td><td><code class="computeroutput">sox</code></td></tr></tbody></table></div></div><br class="table-break"/><p>Other categories schemes can be added to the registry.</p></div></div><div class="section" title="Collections"><div class="titlepage"><div><div><h3 class="title"><a id="id36071429"/>Collections</h3></div></div></div><p>Where an operation could return multiple resources (e.g. categories, searches) this is referred to as a <em class="glossterm">collection</em>. Collections are returned as a list of URLs in <code class="computeroutput">text/uri-list</code> format.<a class="xref" href="#core-rfc2483" title="RFC 2483 - URI Resolution Services Necessary for URN Resolution">RFC2483</a></p><div class="tip" title="Tip" style="margin-left: 0.5in; margin-right: 0.5in;"><h3 class="title">Tip</h3><p>Collections are passed by reference for simplicity rather than performance reasons, requiring O(n+1) requests. Including metadata - (requiring a wrapper format like Atom or SOAP) and/or the data itself - would provide O(1) performance, though passing by value should only be - considered where the representations are known to be small as such - encodings add significant overhead.</p></div><div class="section" title="Examples"><div class="titlepage"><div><div><h4 class="title"><a id="id36070694"/>Examples</h4></div></div></div><pre class="screen"># OCCI Example Collection + (via a wrapper format like Atom or SOAP) and/or the data itself would + provide O(1) performance, though this "pass by value" approach should + only be considered where the representations are known to be small as + encoding adds significant overhead.</p></div><div class="example"><a id="id36071460"/><p class="title"><b>Example 4. Example collection</b></p><div class="example-contents"><pre class="screen"># OCCI Example Collection /examples/custom-extension /examples/lamp-multi-vm /examples/lamp -/examples/myservice</pre></div><div class="section" title="Advertising"><div class="titlepage"><div><div><h4 class="title"><a id="id36070706"/>Advertising</h4></div></div></div><p>Any given URL can be a collection and/or advertise - <em class="glossterm">link</em>s to other - <em class="glossterm">collection</em>s using the - <code class="computeroutput">collection</code> class:</p><pre class="screen">Link: <http://example.com/123/audit>; - rel="http://purl.org/occi/collection/audit"; - title="Audit Entries"</pre><div class="tip" title="Tip" style="margin-left: 0.5in; margin-right: 0.5in;"><h3 class="title">Tip</h3><p>The root (<span class="quote">“<span class="quote">/</span>”</span>) <span class="emphasis"><em>should</em></span> expose - collections <em class="glossterm">in-band</em> and/or - <em class="glossterm">out-of-band</em> in order for clients to discover - resources.</p></div></div><div class="section" title="Paging"><div class="titlepage"><div><div><h4 class="title"><a id="id36070753"/>Paging</h4></div></div></div><p>Collections <span class="emphasis"><em>may</em></span> be divided into +/examples/myservice</pre></div></div><br class="example-break"/><div class="section" title="Paging"><div class="titlepage"><div><div><h4 class="title"><a id="id36071472"/>Paging</h4></div></div></div><p>Collections <span class="emphasis"><em>may</em></span> be divided into <em class="glossterm">page</em>s, with each linking to the <span class="quote">“<span class="quote">first</span>”</span>, <span class="quote">“<span class="quote">last</span>”</span>, <span class="quote">“<span class="quote">next</span>”</span> and - <span class="quote">“<span class="quote">previous</span>”</span> <em class="glossterm">link relation</em>s.</p><pre class="screen">Link: <http://example.com/xyz;start=0>; rel="first" -Link: <http://example.com/xyz;start=400>; rel="previous" -Link: <http://example.com/xyz;start=500>; rel="self" -Link: <http://example.com/xyz;start=600>; rel="next" -Link: <http://example.com/xyz;start=900>; rel="last"</pre></div></div><div class="section" title="Linking"><div class="titlepage"><div><div><h3 class="title"><a id="id36070795"/>Linking</h3></div></div></div><p>Web linking standards for HTTP [<a class="xref" href="#core-link" title="Web Linking">LINK</a>] and + <span class="quote">“<span class="quote">previous</span>”</span> <em class="glossterm">link relation</em>s. The + required <em class="parameter"><code>class</code></em> extension, with the value of + <em class="parameter"><code>paging</code></em>, allows clients to group links together + in the user interface and the server to specify e.g. "Next 10", "Next + 100", etc.</p><pre class="screen">Link: <http://example.com/xyz;start=0>; rel="first"; title="First"; class="paging" +Link: <http://example.com/xyz;start=400>; rel="previous"; title="Previous"; class="paging" +Link: <http://example.com/xyz;start=500>; rel="self"; title="Self"; class="paging" +Link: <http://example.com/xyz;start=600>; rel="next"; title="Next"; class="paging" +Link: <http://example.com/xyz;start=900>; rel="last"; title="Last"; class="paging"</pre></div></div><div class="section" title="Linking"><div class="titlepage"><div><div><h3 class="title"><a id="id36071523"/>Linking</h3></div></div></div><p>Web linking standards for HTTP [<a class="xref" href="#core-link" title="Web Linking">LINK</a>] and HTML [<a class="xref" href="#core-html5" title="HTML 5">HTML5</a>] are used to indicate associations between resources. All formats <span class="emphasis"><em>must</em></span> support <em class="glossterm">in-band</em> linking including:</p><div class="itemizedlist"><ul class="itemizedlist"><li class="listitem"><p>Link relations (e.g. @@ -672,12 +816,7 @@ type="application/pdf"</pre><p><em class="glossterm">Link relation</em>s defined by this standard reside under the <code class="uri">http://purl.org/occi/rel</code> namespace but anyone can define a new <em class="glossterm">link relation</em> by - allocating a URI they control.</p><div class="section" title="Registry Entries"><div class="titlepage"><div><div><h4 class="title"><a id="id36071020"/>Registry Entries</h4></div></div></div><div class="table"><a id="id36071026"/><p class="title"><b>Table 3. Core Link Relations</b></p><div class="table-contents"><table summary="Core Link Relations" border="1"><colgroup><col style="text-align: center"/><col/></colgroup><thead><tr><th style="text-align: left">Relation</th><th>Description</th></tr></thead><tbody><tr><td style="text-align: left"><code class="computeroutput">collection</code> - (<code class="uri">http://purl.org/occi/rel#collection</code>)</td><td><p>A related collection whereby:</p><div class="itemizedlist"><ul class="itemizedlist"><li class="listitem"><p>The root of the collection is indicated by the - <code class="computeroutput">href</code> attribute.</p></li><li class="listitem"><p>The <em class="glossterm">kind</em> of the collection - is indicated by the - <code class="computeroutput">kind</code> extended - attribute.</p></li></ul></div></td></tr><tr><td style="text-align: left"><code class="computeroutput">first</code></td><td><span class="quote">“<span class="quote">An IRI that refers to the furthest preceding + allocating a URI they control.</p><div class="section" title="Registry Entries"><div class="titlepage"><div><div><h4 class="title"><a id="id36071613"/>Registry Entries</h4></div></div></div><div class="table"><a id="id36071619"/><p class="title"><b>Table 3. Core Link Relations</b></p><div class="table-contents"><table summary="Core Link Relations" border="1"><colgroup><col/><col/></colgroup><thead><tr><th style="text-align: left">Relation</th><th>Description</th></tr></thead><tbody><tr><td style="text-align: left"><code class="computeroutput">first</code></td><td><span class="quote">“<span class="quote">An IRI that refers to the furthest preceding resource in a series of resources.</span>”</span> [<a class="xref" href="#core-link" title="Web Linking">LINK</a>]</td></tr><tr><td style="text-align: left"><code class="computeroutput">help</code></td><td><span class="quote">“<span class="quote">The referenced document provides further help information for the page as a whole.</span>”</span> [<a class="xref" href="#core-html5" title="HTML 5">HTML5</a>]</td></tr><tr><td style="text-align: left"><code class="computeroutput">icon</code></td><td><span class="quote">“<span class="quote">The specified resource is an icon representing the page or site, and should be used by the user agent when @@ -687,20 +826,20 @@ ***The diff for this file has been truncated for email.*** ======================================= --- /docs/occi-book.pdf Wed Oct 28 18:16:54 2009 +++ /docs/occi-book.pdf Sun Feb 21 07:32:22 2010 Binary file, no diff available. ======================================= --- /docs/occi-book.xml Wed Oct 28 18:16:54 2009 +++ /docs/occi-book.xml Sun Feb 21 07:32:22 2010 @@ -17,7 +17,7 @@ <contrib>Author</contrib> <affiliation> - <orgname>Australian Online Solutions</orgname> + <orgname>Google</orgname> </affiliation> </author> ============================================================================== Revision: 235906a914 Author: Sam Johnston <samj(a)samj.net> Date: Sun Feb 21 07:33:00 2010 Log: merged http://code.google.com/p/occi/source/detail?r=235906a914

2 1

Joint OCCI/CDMI Demo Schedule
by Hope Hines 19 Feb '10

19 Feb '10

All, Please find attached for your review the demo schedule. Hope Olocity Corporation 1767 Denver West BLVD Suite A Golden, CO 80401 WK: 719-359-8898 Cell: 719-330-4685 www.olocity.com <mailto:Kurt.Krems@Olocity.com> Hope.Hines(a)olocity.com logo_email

1 0

Cloud Computing Use Cases V4 – Discussion on SLAs
by Drussell4881 19 Feb '10

19 Feb '10

On Feb. 12th, we started a thread for topics to become the basis for V4 of the Cloud Computing Use Cases White Paper ( http://groups.google.com/group/cloud-computing-use-cases ), which included: 1) Service Level Agreements 2) Scheduling and Provisioning 3) Asset Management 4) Compliance 5) Moving to the Cloud We have had some great feedback already, but want to delve into each of the proposed topics to better understand the needs of the ecommunity. We will be starting separate threads for each of the above and Service Level Agreements (SLAs) is the first post: In order to understand the interest for SLAs, take a look at potential sub-topics for SLAs and let us know what is missing and which ones are most important to you: * SLAs have to be a legally-binding statement of the user's requirements for security, availability, etc. * Many SLAs (all of them?) should be written in a machine-readable format. * SLAs are tied to metrics. Some of those things are easy to measure (response time, % availability), while others aren't. * SLAs will influence (if not define) cloud management. A machine- readable SLA associated with a VM could tell a cloud vendor where that VM can be hosted, for example. * What about Service Level Objectives? Does anyone have experience with those? What are your thoughts and experiences on existing standards? Are there existing standards for metrics? What other aspects of SLAs are worthy of a whitepaper? As we had with Security and SLAs in Version 3, there's a fair amount of overlap with other potential topics. SLAs are obviously tied to security, but they're also tied to provisioning, scheduling, systems management and other areas. And anyone moving to the cloud should understand how important SLAs are and how they work. In order to consolidate everyone's comments, can you please post to the Use Cases discussion group at http://su.pr/2IBLBO. Look forward to your comments.

1 0

[occi] push by tmetsch - updated copyright year on 2010-02-19 14:32 GMT
by occi＠googlecode.com 19 Feb '10

19 Feb '10

Revision: 4b91cc236c Author: tmetsch@solly Date: Fri Feb 19 06:32:22 2010 Log: updated copyright year http://code.google.com/p/occi/source/detail?r=4b91cc236c Modified: /docs/occi-copyright.xml ======================================= --- /docs/occi-copyright.xml Thu Feb 18 03:13:47 2010 +++ /docs/occi-copyright.xml Fri Feb 19 06:32:22 2010 @@ -42,7 +42,7 @@ <section> <title>Open Grid Forum Copyright Notice</title> - <para>Copyright (C) Open Grid Forum (2009). All Rights Reserved.</para> + <para>Copyright (C) Open Grid Forum (2009-2010). All Rights Reserved.</para> <para>This document and translations of it may be copied and furnished to others, and derivative works that comment on or otherwise explain it or

1 0

OCCI Editor Getting Started Guide (docs/README.txt)
by Sam Johnston 18 Feb '10

18 Feb '10

Afternoon all, As you know I've been quieter than usual lately (I've been busy changing companies/countries) but now I have a little bit of time on my hands I've been fleshing out the OCCI spec. Much of the feedback we've received has been that it's too abstract (which you'll recall was by design following the format wars of 2009) so I've added some examples to help people visualise what's going on. I've also added the following guide to the repository as README.txt so as to make it as easy as possible for others to get involved in the editing of the OCCI documents. I had a clash for the call this week but understand this issue was raised for the 17th time so hopefully this will put it to bed and make it a lot easier for more of you to get involved - if you have any questions you know where to find me. Cheers, Sam Open Cloud Computing Interface (OCCI) Editor Getting Started Guide > Overview ======== > "DocBook is a semantic markup language for technical documentation. It was > originally intended for writing technical documents related to computer > hardware and software but it can be used for any other sort of > documentation." > It was selected for OCCI in order to allow us to maintain a single source > and publish to multiple formats: * HyperText Markup Language (HTML) * Portable Document Format (PDF) * Plain Text (TXT) > Getting Started =============== > You will need the following to get started editing OCCI: * Mercurial (http://mercurial.selenic.com/) * XML Editor (XMLmind: http://www.xmlmind.com/xmleditor/download.shtml) > 1. Download and install Mercurial and your preferred XML editor. 2. Get a local copy of the occi repository with this command: hg clone https://occi.googlecode.com/hg/ occi 3. Edit the DocBook source (Hint: TDG5 is a great resource both for getting > started and as a reference) > Checking In =========== > If you want to check in changes you'll likely need to create a ~/.hgrc file > something like this: > [ui] username = John Citizen <john(a)example.com> > [auth] occi.prefix = occi.googlecode.com/hg/ occi.username = john(a)example.com occi.password = LF3W8dKKJG5X7 occi.schemes = https > You can now commit your changes (with a useful changelog entry please!) > using: hg ci hg push > Rendering ========= > You will need DocBook tools if you want to render the DocBook XML to other > formats (which you should do each time you check in changes): * DocBook XSLT ( > http://sourceforge.net/projects/docbook/files/docbook-xsl-ns/) * Apache FOP Binaries (http://www.apache.org/dyn/closer.cgi/xmlgraphics/fop > ) > Under Mac OS X (using the default Makefile): 1. Extract docbook-xsl-ns into ~/Library/XML/XSL 2. Extract Apache FOP and copy build/fop.jar and lib/*.jar into > /Library/Java/Extensions > Then whenever you make changes simply run "make" to generate new HTML and > PDF versions. > Resources ========= * Official Site (http://www.docbook.org/) * Wikipedia - DocBook (http://en.wikipedia.org/wiki/DocBook) * DocBook 5.0 - The Definitive Guide ( > http://www.docbook.org/tdg5/en/html/docbook.html) * DocBook XSL: The Complete Guide ( > http://www.sagehill.net/docbookxsl/index.html) >

1 0

Demo Topology and conceptual architecture
by Krishna 18 Feb '10

18 Feb '10

All, As per today's discussion, Mark and I collaborated on a preliminary topology and demo architecture diagram. I have uploaded the file. Let us discuss and get to some concurrence via e-mail; that way next week we can firm up the topology and move on to infrastructure setup and software development. Cheers <k/>

1 0

Reminder concall today 10am EDT, 4pm CET, 3pm BST, Thursday 12am Tokyo.
by Thijs Metsch 17 Feb '10

17 Feb '10

Hi, Time again for our weekly concall. Topic of today's concall will be an update of the ongoing work as well as first thoughts about the comments we received yet. For the dial-in details have a look here: http://forge.ogf.org/sf/wiki/do/viewPage/projects.occi-wg/wiki/Teleconferen… Cheers, -Thijs -- Thijs Metsch Tel: +49 (0)941 3075-122 (x60122) http://blogs.sun.com/intheclouds http://www.twitter.com/befreax Software Engineer Cloud, Grid and Virtualization Sun Microsystems GmbH Dr.-Leo-Ritter-Str. 7 mailto:thijs.metsch@sun.com D-93049 Regensburg http://www.sun.com

1 0

Reminder: Cloud Demo call tomorrow
by Mark A. Carlson 16 Feb '10

16 Feb '10

Note: future notices will just go to cloud-demo(a)googlegroups.com What: Cloud Demo coordination planning When: Wednesdays: 8amPT/9amMT/11amET Where: 866-545-5227 code 6300276# Agenda: Status updates: SNIA, OCCI, others? Hosting location ideas? Staging location ideas? Venue planning for first demo - http://www.ogf.org/OGF29/ ? Timeline for first demo Google Group for Cloud Demo http://groups.google.com/group/cloud-demo

1 0

Cloud Computing Use Cases V4 – Open for input on next topic
by Drussell4881 11 Feb '10

11 Feb '10

To start the discussion of topic which will form the base for Version 4 of the paper here are 5 topics to consider and provide feedback : 1)Service Level Agreements 2)Scheduling and Provisioning 3)Asset Management 4)Compliance 5)Moving to the Cloud If there is a topic that is not here that you feel should be considered by the discussion group, do not hesitate to add your topic. A more complete description of the above can be found at http://su.pr/2EPOFq In addition, we are looking at expanding the discussion on Security in the Cloud to a 12 to 15 page document. We would like your input on this thought as well. In order to consolidate your comments, please post your comments to http://su.pr/2EPOFq which is part of the Cloud Computing Use Cases Google Group at http://groups.google.com/group/cloud-computing-use-cases?hl=en_US. In order to post, if you are not already a member, please click on “ Join this Group”.

1 0

Reminder: concall today 10am EDT, 4pm CET, 3pm BST, Thursday 12am Tokyo.
by Thijs Metsch 10 Feb '10

10 Feb '10

Hi, Time again for our weekly concall. Topic of today's concall will be the document which Andy prepared (thanks Andy!) You can review the document over here: https://docs.google.com/Doc?docid=0AS0AExvzzYt7YWQ2enFodmt6czlfMzRnM25mMnJm… For the dial-in details have a look here: http://forge.ogf.org/sf/wiki/do/viewPage/projects.occi-wg/wiki/Teleconferen… Cheers, -Thijs -- Thijs Metsch Tel: +49 (0)941 3075-122 (x60122) http://blogs.sun.com/intheclouds http://www.twitter.com/befreax Software Engineer Cloud, Grid and Virtualization Sun Microsystems GmbH Dr.-Leo-Ritter-Str. 7 mailto:thijs.metsch@sun.com D-93049 Regensburg http://www.sun.com

3 2