Core

Overview

The Open Cloud Computing Interface ("OCCI") is an extensible API for managing Cloud Infrastructure Services (Infrastructure as a Service).

The following reflects the general requirements collected through the specifications of use cases. RFC 2119 requirements levels are used throughout.

Technical specification

Entry Point

Doing a HTTP GET on this end point will return a collection of all resources to which the user has access, in the default rendering format (unless overridden using HTTP Content Negotiation by setting the Accept: header).

This collection should include:

• Descriptions in a suitable format (e.g. OVF)
• Links to operations (e.g. start, stop, restart)
• Links to other resources
• Tags/categories for logical grouping of resources

Central entity

A request to an individual resource will return a representation of the resource in a supported format requested in the HTTP Accept: header, or the default format if none are specified.

Identifiers

Links

CRUD Operations

Create

Construct a document representing the resource in a supported format and submit it via HTTP POST to the appropriate collection (e.g. /compute, /network or /storage).

Retrieve

Make a HTTP GET request to a specific resource (e.g. /compute/id) or a collection (e.g. /compute). The search extension allows results to be limited to one or more matching resources.

Update

Retrieve the resource(s) to be updated, make the required changes and submit them with a HTTP PUT.

Delete

Make a HTTP DELETE request to the URL of the resource.

Meta Model

Nouns Verbs and Attributes

Atom is only used where multiple resources need to be represented in a single HTTP message

OCCI relies on HTTP and Atom as meta-models for individual resources and collections of resources respectively.

• Associations between OCCI resources and to other generic resources (e.g. screenshots, descriptors, etc.) are represented in Link: headers for HTTP and LINK elements for Atom.
• Unique identifiers are represented in the URL for HTTP and ID element for Atom.
• Resource age is represented by Last-Modified: headers for HTTP and UPDATED elements for Atom.
• Resource versioning uses ETags in both instances.

Descriptor format

An earlier, more complex wire protocol discussion has been moved to the WireProtocol page.

Compliant implementations must render resources in the following formats depending on the content type requested by the client.

text/plain (.txt)

type compute
cores 8
cpu 3 Ghz
memory 16 Gb

application/json (.json)

{
  "type": "compute"
  "cores": 8,
  "cpu": "3 Ghz",
  "memory": "16 Gb"
}

application/xml (.xml)

<occi>
  <type>compute</type>
  <cores>8</cores>
  <cpu>3 Ghz</cpu>
  <memory>16 Gb</memory>
</occi>

Collection format

Collections of resources must be rendered as Atom with the requested content type embedded in the CONTENT element:

<?xml version="1.0" encoding="utf-8"?>
<feed xmlns="http://www.w3.org/2005/Atom" xmlns:occi="http://purl.org/occi">
 
<title>Acme Cloud</title>
<link href="http://example.org/" rel="self"/>
<updated>2009-12-31T23:59:59Z</updated>
<author><name>Acme, Inc.</name></author>
<id>urn:uuid:1fddbd00-ce7a-4b64-a71c-3dd14936d1d0</id>
 
<entry>
  <title>Example Virtual Machine</title>
  <id>urn:uuid:d8935668-0862-41c9-a53d-400d781c50e3</id>
  <updated>2009-12-31T23:59:59Z</updated>
  <content type="application/occi+xml">
    <occi:resource>
      <occi:type>compute</occi:type>
      <occi:cores>8</occi:cores>
      <occi:cpu>3 Ghz</occi:cpu>
      <occi:memory>16 Gb</occi:memory>
    </occi:resource>
  </content>
</entry>
 
</feed>

Security

Authentication

For maximum compatibility OCCI relies on HTTP for security, maintaining a registry of supported authentication mechanisms.

Resources should be transparently authenticated such that they can use OCCI for introspection (e.g. a virtual machine could connect to OCCI to discover application configuration parameters, SSH authorized_keys, etc.). Authentication must be transparent and could be based on MAC address, IP address, interface, etc.

Authorisation

Confidentiality & Integrity

Extensions

Internet media type

Future versions of the specification which are not backwards compatible should embed the version so as to avoid having separate entry points for each version (e.g. application/occi2+xml)

Registries

States

XML Namespace

Glossary

OCCI

The Open Cloud Computing Interface

Acknowledgements

• Richard Davies (ElasticHosts)
• Andrew Edmonds (SLA@SOI)
• Sam Johnston (Australian Online Solutions)
• Ignacio M. Llorente (University of Madrid)
• Thijs Metsch (Sun Microsystems)
• Alexis Richardson (Rabbit Technologies and CohesiveFT)
• Simon Wardley (Canonical)
• Chris Webb (ElasticHosts)