The document discusses the Open Cloud Computing Interface (OCCI), which aims to provide an open standard interface for cloud computing. It describes OCCI's goals of allowing interoperability between different cloud providers and preventing vendor lock-in. The core OCCI model defines basic resource and link entity types and supports extensions for additional types and functionality. OCCI uses a RESTful API and represents entities with URIs to allow their creation, retrieval, updating and deletion. Implementations of OCCI have been made for various programming languages and cloud platforms.

1. Open Cloud Computing Interface (OCCI)
Open Cloud Computing Interface (OCCI)
2nd Trentino Cloud Computing Meetup — Trento
Augusto Ciuffoletti
University of Pisa
May 26, 2016
Open Cloud Computing Interface (OCCI)
Summary
• Why OCCI?
• See how simple it is
• Status and perspectives

2. Open Cloud Computing Interface (OCCI)
The problem: too many cloud interfaces
• Each provider has a different interface
• Hybrid, federated clouds need one for all
• Users fear lock-in
• An open standard for cloud interface
• OCCI is cloud IP
• Relationships with OASIS-TOSCA?
Open Cloud Computing Interface (OCCI)
Why OCCI is not TOSCA
• Facts:
• Core OASIS-TOSCA service template definition document
introduces 11 types in 100+ pages
• Core OGF-OCCI core document introduces 2 types in 20
pages
• TOSCA approach tends to be exhaustive, strongly
normative, non expandable
• OCCI approach tends to be minimalistic, costumizable,
extensible
• TOSCA defines a metamodel for defining service topology
and orchestration
• OCCI defines a API interface between a user application
and a provider
• It’s like to compare a watermelon with an apple

3. Open Cloud Computing Interface (OCCI)
OCCI documents structure
• One core doc:
• a meta-meta model that regulates extensions
• a meta-model for cloud resources (core types)
• REST principles regulate the interface
• Extension documents:
• add new types to core ones to model specific kinds of
service
• e.g. IaaS, PaaS, SLA, Monitoring etc.
• Rendering documents
• how to represent entities in various languages
• e.g. plaintext, JSON, XML etc.
• Protocol documents
• the protocol used to implement REST verbs
• e.g. HTTP, XMPP etc.
Open Cloud Computing Interface (OCCI)
OCCI: instances and kinds
• A cloud provision is made of entities
• The type of an entity is indicated by a kind
• A certain kind is characterized by the names and the types
of its attributes
• Kinds are organized in a hierarchy (sub-kinds)
• Two core kinds: resource and link (Lego bricks)
• So you can instantiate entities that are resources or links
• Actions are associated to kinds
• Not executable pieces of code, just headers

4. Open Cloud Computing Interface (OCCI)
Example: IaaS extension
• Historically the first extension to be defined
• An interface for an IaaS provider
• Sub-kinds of the resource are: compute, storage, network
• Sub-kinds of link are: network interface, storage link.
• Some attributes of a compute entity (a few more in the
official doc):
• Architecture
• RAM
• Clock speed
• An action that can be applied to a compute:
• restart
Open Cloud Computing Interface (OCCI)
OCCI: mixins
• Mixins are not new: they exist in Simula, OO Lisp and
other languages
• It is a way to add new capabilities to a class, without
inheritance:
• a mixin is included, not inherited
• In OCCI a Mixin is an aggregate of attributes and actions,
similar to a kind
• A given mixin cannot be instantiated, but only associated
to an already instantiated entity
• Examples:
• an Ubuntu 16.04 mixin is used to declare that a compute
entity has this OS installed
• Mixins, Actions and Kinds are Categories in the meta-meta
model
That’s all for the core model

5. Open Cloud Computing Interface (OCCI)
OCCI: restfulness
• Each entity, type, mixin, action is referred with an URI
• The four REST verbs are used to manipulate entities:
• GET to obtain the definition of an entity
• PUT to create a new entity
• POST to add a subordinate entity in a collection
• DELETE to remove an entity
• Similar for collections of entities
Open Cloud Computing Interface (OCCI)
Extensibility
• 1st method: the provider creates new sub-classes
• Example: IaaS, one further class is a server (i.e. compute
resource kind), or a network link (i.e. network resource
kind), or a network interface (i.e. interface link kind)
• 2nd method: the provider creates new mixins to allow the
user to customize entities

6. Open Cloud Computing Interface (OCCI)
Status of release 1.2
• Minor differences with respect to 1.1 gathering
implementation experience
• Public comment period finished, now in final review by
OGF board
• Documents in the release
• Core Model (*)
• IaaS Extension
• PaaS Extension
• SLA Extension
• HTTP Protocol (*)
• Text Rendering (*)
• JSON Rendering (*)
• The (*) indicates that a compliant interface MUST support
the functionalities described in the document
• A release 2.0 in under way, though unscheduled
Open Cloud Computing Interface (OCCI)
Conclusions
• The OCCI interface is implemented in many languages
(Python, Java, Ruby, Erlang etc.)
• It is adapted to work with many cloud control engines
(OpenStack, OpenNebula, AWS and more)
• Adopted by the EGI cloud infrastructure
• My role: I designed an extension for cloud monitoring, now
an informational document, targeting the inclusion in OCCI
2.0.

7. Open Cloud Computing Interface (OCCI)
Further viewing and reading
• A presentation of the OGF chair during a NIST meeting
(from 35:00 to 52:00)
• see
http://www.nist.gov/itl/cloud/cloud_comp_webcast_viii.cfm
• Browse documents in the OCCI repository:
• https://redmine.ogf.org/projects/occi-wg/repository
• These slides on SlideShare:
• http://www.slideshare.net/AugustoCiuffoletti/open-cloud-
computing-interface-62384843