Open Cloud Computing Interface (Open Grid Forum OGF)

OCCI was initially envisioned as a standard remote API for the management of IaaS based services, such as Virtual Infrastructure Managers, but recently has evolved into a much more flexible standard that covers the full Cloud spectrum, from IaaS to SaaS. The goal of OCCI is to enable the development of interoperable tools by exposing a standard interface allowing tools on an upper layer to be infrastructure-agnostic. The standard focuses on infrastructure resources management operations, such as CRUD (Create-Read-Update-Delete) operations on virtual machines.

The OCCI standard consist on a RESTful API that stands at the same level of the native APIs provided by an Infrastructure Provider, and gives access to the functionalities in the inter- nals of it (see figure 16.1). It is important to remark that the OCCI protocol talks directly to the internals of an IP, not to its API, so in some sense, is a full replacement for the native API.

The OCCI specification consists on a Core Model, defining the core management function- ality, a set of extensions to this core model and a set of “renderings” to interact with the core model and its extensions.

Core Model

The OCCI core model [OW11a] defines a representation system for resources which can be manipulated through a rendering. A fundamental feature of the model is that extensions to the core are visible to clients at run-time, so that a client can discover and understand the various Resources and Link-types supported by the implementation.

1_{http://dmtf.org/standards/cloud}

2_{http://openCloudconsortium.org/}

3_{http://www.Cloudforum.org/}

4_{http://www.gictf.jp/index_e.html}

Figure 16.1: OCCI placement within an IaaS Cloud provider

The main concept in the model is the Resource concept, used to represent, for instance, a virtual machine, a job in a job submission queue, etc. Resources at the same time have a Category and they can have Actions which represents invocable operations on an instance.

Extensions

Currently, the only available extension is the IaaS extension [OW11b], which offers a descrip- tion on how to build an IaaS API following the standard. This extension introduces a set of new resources related to infrastructure concepts: compute (virtual machine), network and storage. The API allows managing these resources in a CRUD style, invoke actions on them, query the provider in order to find out available resources, etc.

Renderings

The concept of Rendering is used in the OCCI to describe a way in which an OCCI-compliant interface can be used. Currently, the only available rendering uses the RESTful protocol [OW11c]. This rendering simply consists on a scheme to define URLs associated to HTTP verbs to access the different actions offered by the API and to discover resources through Queries.

Chapter 17

Requirements Overview

The OPTIMS [ZJB+_{12] consortium has given a lot of importance to requirements from the}

start of the project. As they state: “The quality of requirements has a direct impact on the

chances of success of a project”. In the first year of the project, an initial list of requirements

was developed and was later reviewed and extended in both year 2 and year 3. This section gives an overview of the requirements gathering process and shows the subset of requirements that affect this project. Moreover, these requirements are specialized into a set of new finer- grained requirements that this project will address. The full documentation can be found in the OPTIMIS project website1_.

17.1

Methodology

Several activities were conducted in order to gather both functional and non-functional require- ments for the project. The three main activities that drove the process were:

• The elaboration of a full project glossary capturing the domain vocabulary.

• The use of a scenario-based approach to discover requirements of various stakeholders.

• The use of a goal-oriented methodology to structure those scenarios into goal trees. Three different scenarios were identified and studied, as they cover all areas in which OP- TIMIS results are applicable:

Cloud Programming Model This scenario demonstrates the OPTIMIS toolkit applicability

for Service Providers, both for the construction of new services but also to enable existing legacy applications to take advantage of their deployment in the cloud.

Cloud Bursting This scenario demonstrates the OPTIMIS toolkit applicability for final users

that have deployed services in the cloud and need to have them scale up and down auto- matically.

Cloud Brokerage This use case demonstrates the OPTIMIS toolkit applicability for Cloud

Brokers or Aggregators and how OPTIMIS can integrate multiple clouds.

1_{http://www.optimis-project.eu/sites/default/files/content-files/document/optimis-public-deliverable-d1113-}

These scenarios produced a set of functional requirements which were combined with a second list of requirements that was obtained by using a goal oriented methodology. This methodology is based on the progressive refinement of abstract and general objectives into more concrete goals and requirements. This process led to the identification of the main entities with their relationships and the main agents responsible for the satisfaction of the requirements. The requirements gathered during the first phase of the project were reviewed and extended during the following years by gathering new requirements from OPTIMIS stakeholders and business partners, with special attention to the plans for new use cases and scenarios identified. Moreover, all identified requirements were put in SMART (Specific, Measurable, Attainable, Relevant and Time bound) format and were elicited by using structured templates in which all relevant information of a requirement could be clearly stated (use case mapping, rationale, status, dependencies, etc.).

17.2

Functional Requirements

The following main stakeholders were identified:

End User / Consumer Entity (person or process) who is actually using the service provided

by the Service Provider (SP).

Customer Organization who makes the contract with the SP, in order to get a service (or

application).

Service Provider (SP) The provides of a service/application to the Customer.

Infrastructure Provider (IP) The provider of the infrastructure resources, also known as an

IaaS provider. It provides easy access to computing, storage and networking resources, according to the requests from the SP to deploy and execute his application.

Application/Service developer Developer of an application/service which will be deployed

and executed within the IPs resources. This stakeholder is responsible to make the best use of the OPTIMIS tools, in order to take the maximum advantage of the OPTIMIS- enabled environment.

Broker Sits between the IP and the SP. In addition to providing the abstraction layer of the in-

dividual IPs and their heterogeneous interfaces to the SPs, it provides service governance, matching engine, aggregation and intermediation.

The requirements have been grouped by functional area in the following categories:

Service Management Provides the capability to deploy and govern services across the IPs in

the OPTIMIS network. It also handles bursting operations when they are needed.

Data Management Provides the capability to transfer service images to and between IPs.

Monitoring Provides the capability to monitor services running on IPs and to detect SLA

Component Requirement Service

Management

F1 Be able to deploy an application according to the re- lated service manifest, and be able to undeploy it. F2 To be able to handle a federated scenario by allow-

ing a service to be deployed across multiple IPs. The service should be constructed in a manner that it can be split across multiple targets, deployment should be configured to handle this functionality and runtime services should ensure consistency.

F3 Be able to govern services deployed on OPTIMIS- enabled IP.

Data

Management

F4 Be able to automatically deploy and utilize resources on federated providers. The deployment will be based on pre-existing storage VM templates on the providers. The new VMs will be dynamically de- ployed and contextualized in order to join the existing service

F5 Possibility to migrate VMs from one node to another, in order to redistribute the resources at runtime in function of the changes in the workload patterns.

Monitoring F6 Guarantee interoperability of the Monitoring Infras-

tructure. Collect VM-related monitoring data from cloud middleware recommended by the interoperabil- ity task force.

Table 17.1 shows the list of functional requirements that affect this project the most. Taking this list as a starting point, we have refined the requirements into a new list of finer- grained requirements specific to this project. Moreover, we have prioritized these requirements on a scale of 3 degrees (Low, Medium and High) according to the priority of these requirements as stated by the project consortium.

We have used the template described in section 11.1 of the “Exploring Interoperability at the PaaS layer” part of the project to describe the requirements. The following subsections describe the new requirements for each functional area.