We use proprietary and third party's cookies to improve your experience and our services, identifying your Internet Browsing preferences on our website; develop analytic activities and display advertising based on your preferences. If you keep browsing, you accept its use. You can get more information on our Cookie Policy
Cookies Policy
FIWARE.OpenSpecification.Cloud.IaaS - FIWARE Forge Wiki


From FIWARE Forge Wiki

Jump to: navigation, search
Name FIWARE.OpenSpecification.Cloud.IaaS
Chapter Cloud,
Catalogue-Link to Implementation IaaS Reference Implementation
Owner IBM, Kenneth Nagin


If you need to check out the Open Specs of the previous FIWARE Release (Release 4) you can go to FIWARE.OpenSpecification.Cloud.IaaS R4


Within this document you find a self-contained open specification of a FIWARE generic enabler, please consult as well the FIWARE Product Vision, the website on http://www.fiware.org and similar pages in order to understand the complete context of the FIWARE platform.


Copyright © 2011-2015 by IBM and Intel Corporations

Legal notice

Please check the following Legal Notice to understand the rights to use these specifications.


This specification describes the IaaS GE (renamed from IaaS Resource Management GE), which is a key enabler to build a cloud solution.

The IaaS GE provides the basic Virtual Machine (VM) hosting capabilities, as well as management of the corresponding resources within the Data Center that hosts a particular FIWARE Cloud Instance.

The current release of IaaS GE comprises the core services of OpenStack Kilo Release, as follows:

The main capabilities provided for a cloud hosting user are:

  • Browse VM template catalogue and provision a VM with a specified virtual machine image
  • Manage life cycle of the provisioned VM
  • Manage network and storage of the VM
  • Resource monitoring of the VM
  • Resiliency of the persistent data associated with the VM
  • Manage resource allocation
  • Secure access to the VM

For a cloud hosting provider, the following capabilities are provided:

  • Policy-based resource allocation and optimization
  • Multi-tenancy (support isolation between VMs of different accounts)
  • Automation of typical admin tasks (aimed at decreasing the admin cost)
  • Resiliency of the infrastructure and of the management stack (aimed at reducing outage due to hardware failures)

Basic Concepts

The key concepts visible to the cloud user are:

  • Virtual server, a virtualized container that can host an arbitrary Operating System and arbitrary software stack on top, installed within the virtual server. Virtual servers are also referred as Virtual Machines (VMs) or (virtual) image instances (see definition of virtual image below). The IaaS GE supports provisioning and life cycle management of Virtual Servers.
  • Virtual disk, representing a persistent virtual disk that can be potentially attached to an arbitrary virtual server. The IaaS GE supports provisioning of virtual disks, as well as their attachment to virtual servers.
  • Virtual network, representing a logical network abstraction that would typically represent a network segment at layer 2 of the OSI model. The IaaS GE supports provisioning of virtual networks, as well as attachment of virtual NICs of virtual servers to them.
  • Computing Flavor, a computing flavor is a hardware configuration that can be associated with a virtual server. Each flavor has a unique combination of CPU cores, memory capacity and disk space. An example of this combination could be 8 virtual CPUs, 16 Gb RAM, 10 Gb HDD and 160 Gb of ephemeral disk (a disk that is stored locally on the hypervisor host and is not persistant). Computing flavors must be registered and made available prior to their association to virtual servers.
  • Virtual image, an image is a collection of packaged files used to create or rebuild a virtual server. Basically, a virtual image is a snapshot of a virtual server from which you can create new virtual servers (i.e., image instances). Each virtual server derived from a virtual image hosts the Operating System and software stack associated with the virtual image and is assigned one among the set of available computing flavors, each of which maps to a configuration of computing resources (memory, CPU, etc.). A number of pre-built virtual images can be made available to cloud users but they may also create their own images using tools defined for that purpose. These custom images are useful for backup purposes or for producing "gold" server images if you plan to deploy a particular server configuration frequently. The IaaS GE supports life cycle of virtual images, as well as provisioning of virtual servers based on virtual images.

Main Interactions

IaaS GE provides a wide variety of operations to provision and manage the life cycle of cloud resources. The most important ones are listed below.

Virtual Images

  • listVirtualImages -- Returns a list of all available virtual images (visible by the authenticated user)
  • queryVirtualImages -- Returns a list of available virtual images, filtered by given query criteria
  • getVirtualImageDetails -- Returns details of a virtual image (type, size, creation details, etc.)
  • uploadVirtualImage -- Uploads a new virtual image into the virtual image repository

Virtual Servers


  • createVirtualServer -- Provisions a new virtual server with the given properties (virtual hardware, policy parameters, access, etc). Returns unique ID of the virtual server.
  • destroyVirtualServer -- Removes a virtual server

Power Management

  • powerOnVirtualServer -- Powers on a virtual server
  • powerOffVirtualServer -- Powers off a virtual server
  • RestartVirtualServer -- Restarts a virtual server
  • ShutdownVirtualServer -- Shuts down a virtual server (note: the ability to perform this operation on the fly depends on the capabilities of the underlying virtualization platform)


  • resizeVirtualServer -- Changes the virtual hardware allocation for a virtual server, e.g., allocated RAM or number of CPUs (note: the types of resources for which the reconfiguration can be done on the fly depends on the capabilities of the underlying virtualization platform)


  • getVirtualServerDetails -- Returns details of a virtual server (virtual hardware specification, state, associated policy parameters, access details, etc.)

Virtual Disks


  • createVirtualDisk -- Provisions a new virtual disk with the given properties (size, capabilities, etc.). Returns unique ID of the virtual disk.
  • destroyVirtualDisk -- Removes a virtual disk


  • attachVirtualDisk -- Attaches a given virtual disk to a given virtual server (note: the ability to perform this operation on the fly depends on the capabilities of the underlying virtualization platform)
  • detachVirtualDisk -- Detaches a given virtual disk from a given virtual server (note: the ability to perform this operation on the fly depends on the capabilities of the underlying virtualization platform)


  • getVirtualDiskDetails -- Returns details of a given virtual disk (size, capabilities, attachment details, etc.)

Virtual Networks


  • createVirtualNetwork -- Provisions a new virtual network with the given properties (e.g., VLAN ID, capabilities, etc.). Returns unique ID of the virtual network.
  • destroyVirtualNetwork -- Removes a virtual network


  • attachVirtualServerToNetwork -- Attaches a virtual network interface of a given virtual server to a given virtual network
  • detachVirtualServerFromNetwork -- Detaches a virtual network interface of a given virtual server from a given virtual network


  • getVirtualNetworkDetails -- Returns details of a given virtual network (ID, capabilities, attachment details, etc.)

Basic Design Principles

When applied to IaaS GE, the general design principles outlined at Cloud Hosting Architecture can be translated into the following key design goals:

  • Fully-automated provisioning and life cycle of compute, storage and network resources, requested, managed and released via a standards-based REST API: The REST API allows management of the provisioned resources both through a Web-based user interface or direct API invocation. The API is designed to be abstract and "declarative": a tenant specifies "what" he needs, while the "how" of the provisioning is left to the infrastructural policies and goals. The goal is to provide a standard interface to consume the virtual resource service regardless of the underlying technology used to implement the provisioning infrastructure.
  • High resource utilization, while providing the necessary levels of isolation, availability and performance of provisioned resources: Improved utilization and automation of resources allow greater cost efficiencies for both infrastructure providers and tenants.
  • Ability to dynamically control the amount of allocated resources, as well as to monitor the actual resource usage: Dynamic control of resource provisioning is at the core of application elasticity, enabling the correct sizing of applications' components and operating costs to the varying load conditions.
  • High availability and scalability of the management stack: The infrastructure management components provide availability and scalability through the most advanced current design and development practices, including: fully-distributed shared-nothing architectures to naturally support horizontal scalability, asynchronous communication mechanisms, and extensive automated testing cycles for each contribution.
  • Non-disruptive, automated administrative tasks (e.g., infrastructure maintenance): when scale grows, partial hardware and software failures are the norm rather than the exception. Infrastructure providers require mechanisms to automate administrative tasks reducing the needed effort and preventing any disruption to the tenants' services and applications.
  • Avoid non-authorized access to resources and workloads: Role Based Access Control (RBAC), coupled with an Identity Management service, ensure security by user, role and project.

Detailed Specifications

Following is a list of Open Specifications linked to this Generic Enabler. Specifications labeled as "PRELIMINARY" are considered stable but subject to minor changes derived from lessons learned during last interactions of the development of a first reference implementation planned for the current Major Release of FIWARE. Specifications labeled as "DRAFT" are planned for future Major Releases of FIWARE but they are provided for the sake of future users.

Open API Specifications

The IaaS GE is in fact the OpenStack components: Nova, Glance, Swift, and Neutron. It's current deployment is the OpenStack Kilo Release and as such its API is OpenStack Kilo API:

Re-utilised Technologies/Specifications

This GE leverages the following open source technologies:

  • OpenStack Nova, Kilo release
  • OpenStack Glance, Kilo release
  • OpenStack Cinder, Kilo release
  • OpenStack Neutron, Kilo release

Terms and definitions

This section comprises a summary of terms and definitions introduced during the previous sections. It intends to establish a vocabulary that will be help to carry out discussions internally and with third parties (e.g., Use Case projects in the EU FP7 Future Internet PPP). For a summary of terms and definitions managed at overall FIWARE level, please refer to FIWARE Global Terms and Definitions

  • Infrastructure as a Service (IaaS) -- a model of delivering general-purpose virtual machines (VMs) and associated resources (CPU, memory, disk space, network connectivity) on-demand, typically via a self-service interface and following a pay-per-use pricing model. The virtual machines can be directly accessed and used by the IaaS consumer (e.g., an application developer, an IT provider or a service provider), to easily deploy and manage arbitrary software stacks.
  • Platform as a Service (PaaS) -- an application delivery model in which the clients, typically application developers, follow a specific programming model to develop their applications and or application components and then deploy them in hosted runtime environments. This model enables fast development and deployment of new applications and components.
  • Project is a container of virtual infrastructure that has a set of virtual resources (e.g., computing capacities, storage capacities) to support the former. In other words, a VDC is a pool of virtual resources that supports the virtual infrastructure it contains.
  • Service Elasticity is the capability of the hosting infrastructure to scale a service up and down on demand. There are two types of elasticity -- vertical (typically of a single VM), implying the ability to add or remove resources to a running VM instance, and horizontal (typically of a clustered multi-VM service), implying the ability to add or remove instances to/from an application cluster, on-demand. Elasticity can be triggered manually by the user, or via an Auto-Scaling framework, providing the capability to define and enforce automated elasticity policies based on application-specific KPIs.
  • Service Level Agreement (SLA) is a legally binding contract between a service provider and a service consumer specifying terms and conditions of service provisioning and consumption. Specific SLA clauses, called Service Level Objectives (SLOs), define non-functional aspects of service provisioning such as performance, resiliency, high availability, security, maintenance, etc. SLA also specifies the agreed upon means for verifying SLA compliance, customer compensation plan that should be put in effect in case of SLA incompliance, and temporal framework that defines validity of the contract.
Personal tools
Create a book