Do not edit this page - it's contents are now being transferred to latex.

Now available at: http://forge.ogf.org/svn/repos/occi-wg/trunk/infrastructure.tex

Infrastructure

Changelog

• Update of Category definitions according to new Core&Models.
• Renamed namespace & added more details (http://schemas.ogf.org/occi/2010/10/occi)
• Worked on namespaces for actions...
• "occi.compute.status", "occi.network.status" and "occi.storage.status" renamed to "occi.compute.state", "occi.network.state" and "occi.storage.state"
• Updated all state diagrams to have the initial state as inactive/offline

Status of this Document

This document provides information to the community regarding the specification of the Open Cloud Computing Interface. Distribution is unlimited.

Copyright Notice

Copyright © Open Grid Forum (2009-2010). All Rights Reserved.

Trademarks

OCCI is a trademark of the Open Grid Forum.

1 Abstract

This document, part of a document series, produced by the OCCI working group within the Open Grid Forum (OGF), provides a high-level definition of a Protocol and API. The document is based upon previously gathered requirements and focuses on the scope of important capabilities required to support modern service offerings.

2 Introduction

The Open Cloud Computing Interface (OCCI) is a RESTful Protocol (and API) for all kinds of Management tasks. Originally initiated to create a remote management API for IaaS model based Services, allowing for the development of interoperable tools for common tasks including deployment, autonomic scaling and monitoring, it now can be used to severe other models as well. To be modular and extensible the current specification itself is currently split into three complimentary documents:

1. Core – this defines the OCCI model, common resource types and shared attributes
2. Infrastructure – this defines the infrastructure domain resource types, the required attributes for each and the actions that can be taken on each. (This document)
3. HTTP Rendering - this defines how to manipulate the core model using the OCCI RESTful API. The document defines how the OCCI model can be communicated and thus serialized using HTTP headers.

This document describes OCCI-defined extensions to Resource, Link, Action and assigned Categories for IaaS model based Service providers.

3 Notational Conventions

All these parts and the information within are mandatory for implementors (unless otherwise specified). The key words "MUST", "MUST NOT", "REQUIRED", "SHALL", "SHALL NOT", "SHOULD", "SHOULD NOT", "RECOMMENDED", "MAY", and "OPTIONAL" in this document are to be interpreted as described in RFC 2119.

4 Infrastructure

The infrastructure domain resource types within OCCI, including their specification definitions, are:

• Compute: Information processing resources.
• Network: Interconnection resources.
• Storage: Information recording resources.

These infrastructure resource types inherit Resource base type and all its attributes. OCCI implementors MUST implement these. The HTTP Rendering document define how to interact with these resource types using RESTful communication. OCCI makes an ideal interoperable boundary interface between the web and the internal resource management system of infrastructure providers.

As REQUIRED by the OCCI Core specification every resource type instantiated that is a subclass of Resource MUST be assigned a Category that identifies the instantiated resource type. Each such Category MUST be related to the Resource base type Category. These Categories, the core categories, MUST always remain immutable to any client.

The following table describe the Category defined for each of the infrastructure Resource subtypes:

The following sections on Compute, Storage and Network detail the Attributes and Actions defined for each resource type.

4.1 Compute

The Compute Resource type is assigned the http://schemas.ogf.org/occi/infrastructure#compute Category. A Compute Resource instance MUST at least expose this Category.

4.1.1 Attributes

The attributes that MUST be exposed by an instance of the Compute Resource type are as follows:

4.1.2 Actions

Actions can be performed upon instances of the Compute Resource type. The set that MUST be supported are as follows:

4.1.3 States

Below illustrates the state diagram based on the actions defined above in 4.1.2.

4.2 Network

The Network Resource type is assigned the http://schemas.ogf.org/occi/infrastructure#network Category. A Network Resource instance MUST at least expose this Category.

4.2.1 Attributes

The attributes that MUST be exposed by an instance of the Network Resource type are as follows:

4.2.2 Actions

Actions can be performed upon instances of the Storage Resource type. The set that must be supported are as follows:

4.2.3 States

Below illustrates the state diagram based on the actions defined above in 4.2.2.

4.3 Storage

The Storage Resource type is assigned the http://schemas.ogf.org/occi/infrastructure#storage Category. A Storage Resource instance MUST at least expose this Category.

4.3.1 Attributes

The attributes that MUST be exposed by an instance of the Storage Resource type are as follows:

4.3.2 Actions

Actions can be performed upon instances of the Storage Resource type. The set that MUST be supported are as follows:

4.3.3 States

Below illustrates the state diagram based on the actions defined above in 4.3.2.

5 Contributors

• Editors: Andy Edmonds, Thijs Metsch
• Contributors: Ralf Nyrén, Sam Johnston

6 Glossary

7 Intellectual Property Statement

The OGF takes no position regarding the validity or scope of any intellectual property or other rights that might be claimed to pertain to the implementation or use of the technology described in this document or the extent to which any license under such rights might or might not be available; neither does it represent that it has made any effort to identify any such rights. Copies of claims of rights made available for publication and any assurances of licenses to be made available, or the result of an attempt made to obtain a general license or permission for the use of such proprietary rights by implementers or users of this specification can be obtained from the OGF Secretariat.

The OGF invites any interested party to bring to its attention any copyrights, patents or patent applications, or other proprietary rights which may cover technology that may be required to practice this recommendation. Please address the information to the OGF Executive Director.

8 Disclaimer

This document and the information contained herein is provided on an “As Is” basis and the OGF disclaims all warranties, express or implied, including but not limited to any warranty that the use of the information herein will not infringe any rights or any implied warranties of merchantability or fitness for a particular purpose.

9 Full Copyright Notice

Copyright (C) Open Grid Forum (2009-2010). All Rights Reserved.

This document and translations of it may be copied and furnished to others, and derivative works that comment on or otherwise explain it or assist in its implementation may be prepared, copied, published and distributed, in whole or in part, without restriction of any kind, provided that the above copyright notice and this paragraph are included on all such copies and derivative works. However, this document itself may not be modified in any way, such as by removing the copyright notice or references to the OGF or other organizations, except as needed for the purpose of developing Grid Recommendations in which case the procedures for copyrights defined in the OGF Document process must be followed, or as required to translate it into languages other than English.

The limited permissions granted above are perpetual and will not be revoked by the OGF or its successors or assignees.

10 References

Note that only permanent documents should be cited as references. Other items, such as Web pages or working groups, should be cited inline (i.e., see the Open Grid Forum, http://www.ogf.org). References should conform to a standard such as used by IEEE/ACM, MLA, Chicago or similar. Include an author, year, title, publisher, place of publication. For online materials, also add a URL. It is acceptable to separate out “normative references,” as IETF documents typically do. Some sample citations:

Attachments:

storage-state-1.png [Infrastructure/storage-state-1.png] network-state-1.png [Infrastructure/network-state-1.png] compute-state-1.png [Infrastructure/compute-state-1.png] storage-state.png [Infrastructure/storage-state.png] network-state.png [Infrastructure/network-state.png] compute-state.png [Infrastructure/compute-state.png]