Cloud Infrastructure Management Interface (CIMI)
The CIMI is a standard in progress that comes from the Cloud Management Working Group (CMWG) of the Distributed Management Task Force (DMTF). The DMTF published version one of CIMI as a standard in September 2012 and followed this with version 1.1.0 in October 2013. The document describes the model and protocol for management interactions between an IaaS provider and IaaS consumers and focuses on a REST style-protocol using HTTP but the interface design separates the interface from the communication protocol in order to support the same interface with different interaction styles making it possible to map to other protocols. It is a straightforward model that gives adequate detail without becoming overly complex. It is able to do this because it simply addresses the needs of a cloud management interface without the need to model all that is deployable and implemented in the IT infrastructure on a IaaS cloud.
CIMI Model
An important piece of the CIMI interface is resources, these represent key entities of IaaS. Such resources include machines, storage volumes, and networks. The model itself is not a formal structure, but it assumes an existing business relationship and the process of a user choosing a configuration and deploying it. It gives an implicit pattern that the resources follow, and each resource has a template resource, configuration resources, and the resource specification. The template provides a description of a resource that allows providers to offer a catalogue of blueprints to consumers. Users can then, in most instances, offer variations on the templates, if they do not choose the preexisting design, these variation will become a configuration resource.
Resources
The resources themselves are addressable and accessed, created, modified, deleted, and operated on using basic HTP methods.
Cloud Entry Point – Although a resource itself, the Cloud Entry Point provides a URI through which a consumer can access a catalogue of resources available from the provider.
Machines – CIMI Machines are abstractions of a single computer system and can be either virtual or physical machines. From the Cloud Entry Point the consumer retrieves a list of resources and from this a list of machine images, configurations, and templates. They can then use these specifications to instantiate a machine.
Volumes – CIMI Volumes represent storage. It is instantiated in the same way in which a Machine is, however it must be associated with a machine in order for it to work.
Network – The Network resources are an abstraction of a transport network and the resources are Network, Network Port, Address, and Forwarding Group.
Monitoring – These monitoring resources comprise of Job, Meter, and Event. The Job resource is related to operations and a consumer can query a Job resource to determine the state of CIMI operation. The Meter resource monitors the health and performance of the system. And finally the Events resource is created by the provider and represent any information that the provider tracks.
System – The system resource is potentially the most powerful and useful to the consumer, however it would lose all value were it not for the other resources. The system resources represent group of resources. These resources will have been designed to work together by service designers, in most instances. This allows for system templates that provide patterns that portray the infrastructure of a complex service consisting of various resources. These templates can be used to recreate this infrastructure consistently.
Articles and Publications | Standards |
|---|---|
| CIMI and TOSCA | CIMI |
Open Cloud Computing Interface (OCCI)
OCCI is a set of open standards and specifications published by the Open Grid Forum in three categories in 2011. While it has similar goals to CIMI the two differ. Both aim for an interface for IaaS clouds and two of the three OCCI categories focus on a REST-style interface.
The first OCCI category is the core document, is a high-level description of the interface. This document describes an abstract system and although OCCI focuses on IaaS, the core document points out that it could apply to both PaaS and SaaS. The next category is OCCI Rendering and this consists of multiple documents all describing particular renderings of the core document. The final category is OCCI Extension and this is made from multiple documents describing a particular extension of the OCCI model, all of these complementary documents aim to make the OCCI specification modular and extensible.
The primary element in the OCCI Core Model is the Resource. Resources describe a concrete source that can be inspected and manipulated, it could represent virtual machines, services etc. Links define relationships between Resources, and both Resources and Links are derived from an abstract class called Entity. Because they are derivatives, both Resources and Links share the same characteristics of Entities.
Entities – Whilst the Entity class is common to both Resources and Links, several other OCCI classes are associated with entities; these are Kinds, Mixins, and Actions. Because of this both Resources and Links share connections with these classes.
Kinds – A Kind class is the name given to some characteristic or quality that categories of resources are defined by.
Mixin – A Mixin allows to core OCCI Model to be extended.
Actions – Actions represent the processes that can be carried out on resources in order to create a state change or also to create new resources.
Categories – Categories give information on a number Kinds, Mixins and Actions as a single entity, it ties together Resource characteristics into a single package.
Articles and Publications | Standards |
|---|---|
| About OCMI | OCCI Core |
| OCCI Rendering | |
| OCCI Infrastructure Extension |