Large-scale Integrated Project (IP) - CORDIS · FIWARE.OpenSpecification.Cloud.DCRM ... IoT,...
Transcript of Large-scale Integrated Project (IP) - CORDIS · FIWARE.OpenSpecification.Cloud.DCRM ... IoT,...
-
Private Public Partnership Project (PPP)
Large-scale Integrated Project (IP)
D.4.1.3: FI-WARE GE Open Specification
Project acronym: FI-WARE Project full title: Future Internet Core Platform Contract No.: 285248 Strategic Objective: FI.ICT-2011.1.7 Technology foundation: Future Internet Core Platform Project Document Number: ICT-2011-FI-285248-WP4-D.4.1.3 Project Document Date: 2014-06-15 Deliverable Type and Security: Public Author: FI-WARE Consortium Contributors: FI-WARE Consortium
https://forge.fi-ware.org/plugins/mediawiki/wiki/fiware/index.php/File:FP7Portrait_logo.jpghttps://forge.fi-ware.org/plugins/mediawiki/wiki/fiware/index.php/File:FI-WARE_logo.png
-
Future Internet Core Platform
D.4.1.3 FI-WARE GE Open Specification Page 2
1.1 Executive Summary
This document describes the Generic Enablers in the Cloud Hosting chapter, their basic functionality and their interaction. Each GE Open Specification is first described at a generic level, describing the functional and non-functional properties and is supplemented by a number of specifications according to the interface protocols, API and data formats.
https://forge.fi-ware.org/plugins/mediawiki/wiki/fiware/index.php/File:FI-WARE_logo.png
-
Future Internet Core Platform
D.4.1.3 FI-WARE GE Open Specification Page 3
1.2 About This Document
FI-WARE GE Open Specifications describe the open specifications linked to Generic Enablers GEs of the FI-WARE project (and their corresponding components) being developed in one particular chapter.
GE Open Specifications contain relevant information for users of FI-WARE to consume related GE implementations and/or to build compliant products, which can work as alternative implementations of GEs developed in FI-WARE. The later may even replace a GE implementation developed in FI-WARE within a particular FI-WARE instance. GE Open Specifications typically include, but not necessarily are limited to, information such as:
Description of the scope, behavior and intended use of the GE
Terminology, definitions and abbreviations to clarify the meanings of the specification
Signature and behavior of operations linked to APIs (Application Programming Interfaces) that the GE should export. Signature may be specified in a particular language binding or through a RESTful interface.
Description of protocols that support interoperability with other GE or third party products
Description of non-functional features
1.3 Intended Audience
The document targets interested parties in architecture and API design, implementation and usage of FI-WARE Generic Enablers from the FI-WARE project.
1.4 Chapter Context
The Cloud Chapter offers Generic Enablers that comprise the foundation for designing a modern cloud hosting infrastructure that can be used to develop, deploy and manage Future Internet applications and services, as outlined in Materializing Cloud Hosting in FI-WARE.
The capabilities available in the second release of FI-WARE Cloud Hosting platform are outlined in Roadmap of Cloud Hosting.
The following diagram shows the main components (Generic Enablers) that comprise the second release of FI-WARE architecture.
https://forge.fi-ware.org/plugins/mediawiki/wiki/fiware/index.php/File:FI-WARE_logo.pnghttps://forge.fi-ware.org/plugins/mediawiki/wiki/fiware/index.php/Materializing_Cloud_Hosting_in_FI-WAREhttps://forge.fi-ware.org/plugins/mediawiki/wiki/fiware/index.php/Materializing_Cloud_Hosting_in_FI-WAREhttps://forge.fi-ware.org/plugins/mediawiki/wiki/fiware/index.php/Roadmap_of_Cloud_Hosting
-
Future Internet Core Platform
D.4.1.3 FI-WARE GE Open Specification Page 4
The architecture comprises a set of Generic Enablers that together provide hosting capabilities of several kinds and at several levels of resource abstraction -- aiming at the needs of different applications hosted on the cloud platform. IaaS Data Center Resource Management (DCRM) GE is offering provisioning and life cycle management of virtualized resources (compute, storage, network) associated with virtual machines, which can run general purpose Operating Systems as well as arbitrary software stacks. Application developers and providers can use these virtual machines to develop and deploy their own software components that comprise their application stacks. Object Storage GE offers provisioning and life cycle management of object-based storage containers and elements, which can be efficiently used to store unstructured fixed content (such as images, videos, etc) as well as accompanying metadata. Job Scheduler GE offers the application to submit and manage computational jobs in a unified and scalable manner. Edgelet Management GE offers the capability to host lightweight application components, called edgelets, on devices typically located outside of the Data Center, such as those provided by the Cloud Proxy GE (developed jointly by the Cloud chapter and the Interfaces to Network and Devices chapter). Software Deployment and Configuration (SDC) GE offers a flexible framework for installation and customization of software products within individual virtual machines. Policy Manager GE provides a framework for rule-based management of cloud resources, including application auto-scaling based leveraging metrics collected by Monitoring GE. Lastly, PaaS Management GE uses the above capabilities to offer holistic provisioning and ongoing management of complex workloads comprising sophistical combination of interdependent VMs and associated resources (such as multi-tier web applications or even complete custom-built PaaS environments), as well as configuration and management of software components within the VMs. Each of the above GEs provides a REST API that can be used programmatically. The human actor represents the programmatic user of the different capabilities of the Cloud GEs via REST APIs. Moreover, the Cloud chapter provides a Web-based Portal (part of of the UI layer) , which surfaces main capabilities in an interactive manner --such as provisioning and monitoring of VM instances and services. Cloud Hosting Generic Enablers are using the Identity Management and Access Control framework provided by the Security chapter, as outlined in the Cloud Security Architecture.
1.5 Structure of this Document
The document is generated out of a set of documents provided in the public FI-WARE wiki. For the current version of the documents, please visit the public wiki at http://wiki.fi-ware.eu/
The following resources were used to generate this document:
https://forge.fi-ware.org/plugins/mediawiki/wiki/fiware/index.php/File:FI-WARE_logo.pnghttps://forge.fi-ware.org/plugins/mediawiki/wiki/fiware/index.php/File:FI-WARE_Cloud_Architecture_M36.pnghttp://forge.fi-ware.eu/plugins/mediawiki/wiki/fiware/index.php/Testbed_Security_Architecturehttp://forge.fi-ware.eu/plugins/mediawiki/wiki/fiware/index.php/Testbed_Security_Architecturehttp://wiki.fi-ware.eu/
-
Future Internet Core Platform
D.4.1.3 FI-WARE GE Open Specification Page 5
D.4.1.3 FI-WARE GE Open Specifications front page
FIWARE.OpenSpecification.Cloud.DCRM
DCRM OpenStack Open RESTful API Specification
DCRM OCCI Open RESTful API Specification
FIWARE.OpenSpecification.Cloud.SelfServiceInterfaces
FIWARE.OpenSpecification.Cloud.ObjectStorage
Object Storage Open RESTful API Specification
FIWARE.OpenSpecification.Cloud.SDC
SDC Open RESTful API Specification
FIWARE.OpenSpecification.Cloud.PaaS
PaaS Open RESTful API Specification
FIWARE.OpenSpecification.Cloud.Monitoring
Monitoring Open RESTful API Specification
FIWARE.OpenSpecification.Cloud.PolicyManager
Policy Manager Open RESTful API Specification
FIWARE.OpenSpecification.Cloud.JobScheduler
Job Scheduler Open RESTful API Specification
FIWARE.OpenSpecification.Cloud.Edgelets
Edgelets Open API Specification
1.6 Typographical Conventions
Starting with October 2012 the FI-WARE project improved the quality and streamlined the submission process for deliverables, generated out of the public and private FI-WARE wiki. The project is currently working on the migration of as many deliverables as possible towards the new system.
This document is rendered with semi-automatic scripts out of a MediaWiki system operated by the FI-WARE consortium.
1.6.1 Links within this document
The links within this document point towards the wiki where the content was rendered from. You can browse these links in order to find the "current" status of the particular content.
Due to technical reasons not all pages that are part of this document can be linked document-local within the final document. For example, if an open specification references and "links" an API specification within the page text, you will find this link firstly pointing to the wiki, although the same content is usually integrated within the same submission as well.
https://forge.fi-ware.org/plugins/mediawiki/wiki/fiware/index.php/File:FI-WARE_logo.pnghttps://forge.fi-ware.org/plugins/mediawiki/wiki/fiware/index.php/FIWARE.OpenSpecification.Cloud.DCRMhttps://forge.fi-ware.org/plugins/mediawiki/wiki/fiware/index.php/DCRM_OpenStack_Open_RESTful_API_Specificationhttps://forge.fi-ware.org/plugins/mediawiki/wiki/fiware/index.php/DCRM_OCCI_Open_RESTful_API_Specificationhttps://forge.fi-ware.org/plugins/mediawiki/wiki/fiware/index.php/FIWARE.OpenSpecification.Cloud.SelfServiceInterfaceshttps://forge.fi-ware.org/plugins/mediawiki/wiki/fiware/index.php/FIWARE.OpenSpecification.Cloud.ObjectStoragehttps://forge.fi-ware.org/plugins/mediawiki/wiki/fiware/index.php/Object_Storage_Open_RESTful_API_Specificationhttps://forge.fi-ware.org/plugins/mediawiki/wiki/fiware/index.php/FIWARE.OpenSpecification.Cloud.SDChttps://forge.fi-ware.org/plugins/mediawiki/wiki/fiware/index.php/SDC_Open_RESTful_API_Specificationhttps://forge.fi-ware.org/plugins/mediawiki/wiki/fiware/index.php/FIWARE.OpenSpecification.Cloud.PaaShttps://forge.fi-ware.org/plugins/mediawiki/wiki/fiware/index.php/PaaS_Open_RESTful_API_Specificationhttps://forge.fi-ware.org/plugins/mediawiki/wiki/fiware/index.php/FIWARE.OpenSpecification.Cloud.Monitoringhttps://forge.fi-ware.org/plugins/mediawiki/wiki/fiware/index.php/Monitoring_Open_RESTful_API_Specificationhttps://forge.fi-ware.org/plugins/mediawiki/wiki/fiware/index.php/FIWARE.OpenSpecification.Cloud.PolicyManagerhttps://forge.fi-ware.org/plugins/mediawiki/wiki/fiware/index.php/Policy_Manager_Open_RESTful_API_Specificationhttps://forge.fi-ware.org/plugins/mediawiki/wiki/fiware/index.php/FIWARE.OpenSpecification.Cloud.JobSchedulerhttps://forge.fi-ware.org/plugins/mediawiki/wiki/fiware/index.php/Job_Scheduler_Open_RESTful_API_Specificationhttps://forge.fi-ware.org/plugins/mediawiki/wiki/fiware/index.php/FIWARE.OpenSpecification.Cloud.Edgeletshttps://forge.fi-ware.org/plugins/mediawiki/wiki/fiware/index.php/Edgelets_Open_API_Specification
-
Future Internet Core Platform
D.4.1.3 FI-WARE GE Open Specification Page 6
1.6.2 Figures
Figures are mainly inserted within the wiki as the following one:
[[Image:....|size|alignment|Caption]]
Only if the wiki-page uses this format, the related caption is applied on the printed document. As currently this format is not used consistently within the wiki, please understand that the rendered pages have different caption layouts and different caption formats in general. Due to technical reasons the caption can't be numbered automatically.
1.6.3 Sample software code
Sample API-calls may be inserted like the following one.
http://[SERVER_URL]?filter=name:Simth*&index=20&limit=10
1.7 Acknowledgements
The following partners contributed to this deliverable: IBM, TID, INTEL, UPM, TRDF, Inria, THALES
1.8 Keyword list
FI-WARE, PPP, Roadmap, Reference Architecture, Generic Enabler, Open Specifications, I2ND, Cloud, IoT, Data/Context Management, Applications/Services Ecosystem, Delivery Framework, Security, Developers Community and Tools
1.9 Changes History
Release Major changes description Date Editor
v1 Draft of deliverable submission 2014-05-25 IBM
v2 Updated document 2014-06-15 IBM
https://forge.fi-ware.org/plugins/mediawiki/wiki/fiware/index.php/File:FI-WARE_logo.pnghttps://forge.fi-ware.org/plugins/mediawiki/wiki/fiware/index.php/IBMhttps://forge.fi-ware.org/plugins/mediawiki/wiki/fiware/index.php/TIDhttps://forge.fi-ware.org/plugins/mediawiki/wiki/fiware/index.php/INTELhttps://forge.fi-ware.org/plugins/mediawiki/wiki/fiware/index.php/UPMhttps://forge.fi-ware.org/plugins/mediawiki/wiki/fiware/index.php/TRDFhttps://forge.fi-ware.org/plugins/mediawiki/wiki/fiware/index.php/Inriahttps://forge.fi-ware.org/plugins/mediawiki/wiki/fiware/index.php/THALES
-
Future Internet Core Platform
D.4.1.3 FI-WARE GE Open Specification Page 7
1.10 Table of Contents
2 FIWARE OpenSpecification Cloud DCRM .......................................................... 8
3 DCRM OpenStack Open RESTful API Specification ........................................ 16
4 DCRM OCCI Open RESTful API Specification ................................................. 22
5 FIWARE OpenSpecification Cloud SelfServiceInterfaces ................................. 36
6 FIWARE OpenSpecification Cloud ObjectStorage ............................................ 40
7 Object Storage Open RESTful API Specification .............................................. 47
8 FIWARE OpenSpecification Cloud SDC ........................................................... 56
9 SDC Open RESTful API Specification .............................................................. 63
10 FIWARE OpenSpecification Cloud PaaS ...................................................... 79
11 PaaS Open RESTful API Specification ......................................................... 89
12 FIWARE OpenSpecification Cloud Monitoring ............................................ 116
13 Monitoring Open RESTful API Specification ............................................... 124
14 FIWARE OpenSpecification Cloud PolicyManager ..................................... 134
15 Policy Manager Open RESTful API Specification ....................................... 146
16 FIWARE OpenSpecification Cloud JobScheduler ....................................... 162
17 Job Scheduler Open RESTful API Specification ......................................... 173
18 FIWARE OpenSpecification Cloud Edgelets ............................................... 219
19 Edgelets Open API Specification ................................................................ 224
https://forge.fi-ware.org/plugins/mediawiki/wiki/fiware/index.php/File:FI-WARE_logo.png
-
Future Internet Core Platform
D.4.1.3 FI-WARE GE Open Specification Page 8
2 FIWARE OpenSpecification Cloud DCRM
2.1 Preface
Within this document you find a self-contained open specification of a FI-WARE generic enabler, please consult as well the FI-WARE_Product_Vision, the website on http://www.fi-ware.org and similar pages in order to understand the complete context of the FI-WARE project.
2.2 Copyright
Copyright © 2011-2014 by IBM and Intel Corporations
2.3 Legal notice
Please check the following Legal Notice to understand the rights to use these specifications.
2.4 Overview
This specification describes the DataCenter Resource Management (DCRM) GE, which is a key enabler to build a cloud solution.
The DCRM GE provides the basic Virtual Machine (VM) hosting capabilities, as well as management of the corresponding resources within the DataCenter that hosts a particular FI-WARE Cloud Instance.
The baseline for the DCRM GE is OpenStack. Hence, DCRM offers all the capabilities that OpenStack natively provides to cloud hosting users and cloud hosting providers plus some unique extended capabilities. 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 (with guarantees)
Secure access to the VM
For a cloud hosting provider, the following capabilities are provided:
Resource optimization and over-commit (aimed at increasing the utilization and decreasing the hardware cost)
Capacity management and admission control (allowing to easily monitor and control the capacity and the utilization of the infrastructure)
Multi-tenancy (support isolation between VMs of different accounts)
Automation of typical admin tasks (aimed at decreasing the admin cost)
https://forge.fi-ware.org/plugins/mediawiki/wiki/fiware/index.php/File:FI-WARE_logo.pnghttps://forge.fi-ware.org/plugins/mediawiki/wiki/fiware/index.php/FI-WARE_Product_Visionhttp://www.fi-ware.org/https://forge.fi-ware.org/plugins/mediawiki/wiki/fiware/index.php/FI-WARE_Open_Specification_Legal_Notice_(implicit_patents_license)
-
Future Internet Core Platform
D.4.1.3 FI-WARE GE Open Specification Page 9
Resiliency of the infrastructure and of the management stack (aimed at reducing outage due to hardware failures)
2.4.1 DCRM components
The following diagram shows the main components of the DCRM GE, as well as its main interactions.
Main components of the DCRM Architecture
On the above diagram, the API component is the front-end of DCRM. It can be implemented either as a set of endpoints handling each of the resource types -- virtual servers, virtual disks, virtual networks and virtual images, or a single endpoint dispatching the incoming requests to the corresponding 'backend' runtime. At the back-end, different aspects of resource management are handled by corresponding internal services, such as policy service and placement service.
2.4.2 DCRM-specific features
With respect to the OpenStack baseline, DCRM provides in addition the following set of high-level advanced features:
Shared storage configuration enabling live VM migration and related scenarios
VM High Availability
Adaptive scheduling for optimized resource utilization
Support for QoS guarantees for workloads
Support for placement policies
Support of concurrent management and deployment workflows in a scalable consistent manner
Unified management of heterogeneous environments
https://forge.fi-ware.org/plugins/mediawiki/wiki/fiware/index.php/File:FI-WARE_logo.pnghttps://forge.fi-ware.org/plugins/mediawiki/wiki/fiware/index.php/File:DCRMArchitecture.png
-
Future Internet Core Platform
D.4.1.3 FI-WARE GE Open Specification Page 10
Support for policy-based virtual network connectivity
2.4.3 Extended capabilities with respect to OpenStack
The high-level features listed above are enabled by the combination of a set of extended capabilities that can also be used in isolation. They are:
Host failure detection (Zookeeper): enables the automatic recovery of VMs from a failed host
Advanced Scheduler:
o Flexible global resource optimization based on large and extensible set of metrics, including resource utilization: enables the implementation and configuration of several resource utilization optimization policies for infrastructure providers
o Ongoing placement optimization using live migration and a solver: live migration of VMs across hosts allows continuous optimization of VMs placement according to configurable policies with no service disruption
o Placement support for automated HA of VM instances: in an HA scenario, if a host fails, the placement logic will automatically provide correct placement for all recovered VMs
o Host evacuation support: this capability simplifies infrastructure management tasks by automatically moving out all VMs from one host (host maintenance scenario)
o Support for anti-affinity / placement policies: this capability allows cloud users to specify constraints and requirements with respect to VMs placement. This capability enables both service availability and VM proximity scenarios for cloud applications
o HA-aware admission control: this mechanism is used to guarantee that at all times the system will have sufficient host spare capacity to recover from a single host failure
o Unified support for heterogeneous performance of the underlying HW: a translation layer is used to assign correct VCPU nominal performance on heterogeneous hosts. This prevents wasting capacity and enables optimal resource utilization
o Fine-grained compatibility verification: it prevents VMs from being deployed on incompatible HW
o Flexible resource allocation policies and adaptive resource over-commit based on idleness detection: VM admission control adapts to the number of idle VMs in the system, maximizing resource utilization
2.5 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). DCRM GE supports provisioning and life cycle management of Virtual Servers.
https://forge.fi-ware.org/plugins/mediawiki/wiki/fiware/index.php/File:FI-WARE_logo.png
-
Future Internet Core Platform
D.4.1.3 FI-WARE GE Open Specification Page 11
Virtual disk, representing a persistent virtual disk that can be potentially attached to an arbitrary virtual server. DCRM 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. DCRM 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 to 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). 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 to 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. DCRM GE supports life cycle of virtual images, as well as provisioning of virtual servers based on virtual images.
2.6 Main Interactions
DCRM provides a wide variety of operations to provision and manage the life cycle of cloud resources. The most important ones are listed below as conceptional operations, the API itself might use different syntax and is specified in the API specification section.
2.6.1 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
https://forge.fi-ware.org/plugins/mediawiki/wiki/fiware/index.php/File:FI-WARE_logo.png
-
Future Internet Core Platform
D.4.1.3 FI-WARE GE Open Specification Page 12
2.6.2 Virtual Servers
2.6.2.1 Provisioning
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
2.6.2.2 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)
2.6.2.3 Reconfiguration
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)
2.6.2.3.1 Inventory getVirtualServerDetails -- Returns details of a virtual server (virtual
hardware specification, state, associated policy parameters, access details, etc.)
2.6.3 Virtual Disks
2.6.3.1 Provisioning
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
2.6.3.2 Attachment
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)
2.6.3.3 Inventory
getVirtualDiskDetails -- Returns details of a given virtual disk (size, capabilities, attachment details, etc.)
https://forge.fi-ware.org/plugins/mediawiki/wiki/fiware/index.php/File:FI-WARE_logo.png
-
Future Internet Core Platform
D.4.1.3 FI-WARE GE Open Specification Page 13
2.6.4 Virtual Networks
2.6.4.1 Provisioning
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
2.6.4.2 Attachment
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
2.6.4.3 Inventory
getVirtualNetworkDetails -- Returns details of a given virtual network (ID, capabilities, attachment details, etc.)
2.6.5 Example Scenario
The following sequence of operations describes a typical (simple) scenario of provisioning of a virtual server hosted in the Cloud:
User authenticates with Identity Management GE, receives a token
User creates ssh key-pair, to be used to authenticate with the guest OS within the virtual server instances
User retrieves a list of available images and of virtual server flavors
User requests a new virtual server
User verifies that the virtual server creation has completed
User retrieves the IP address allocated for the virtual server
User connects to the virtual server using ssh
https://forge.fi-ware.org/plugins/mediawiki/wiki/fiware/index.php/File:FI-WARE_logo.png
-
Future Internet Core Platform
D.4.1.3 FI-WARE GE Open Specification Page 14
2.7 Basic Design Principles
When applied to DCRM, 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
https://forge.fi-ware.org/plugins/mediawiki/wiki/fiware/index.php/File:FI-WARE_logo.pnghttps://forge.fi-ware.org/plugins/mediawiki/wiki/fiware/index.php/File:DCRM-Arch-Sequence-Diag.pnghttps://forge.fi-ware.org/plugins/mediawiki/wiki/fiware/index.php/Cloud_Hosting_Architecturehttps://forge.fi-ware.org/plugins/mediawiki/wiki/fiware/index.php/Cloud_Hosting_Architecture
-
Future Internet Core Platform
D.4.1.3 FI-WARE GE Open Specification Page 15
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.
FIWARE.OpenSpecification.Details.Cloud.DCRM
2.8 Re-utilised Technologies/Specifications
The DCRM OpenStack API is a RESTful, resource-oriented API accessed via HTTP that uses XML-based and/or JSON-based representations for information interchange. It builds on top of the Compute, Identity, Images, and Network OpenStack API v2.0, but it extends the original specifications to provide support to additional DCRM-specific management features currently not available in OpenStack.
2.9 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 FI-WARE level, please refer to FIWARE Global Terms and Definitions
FIWARE.Glossary.DCRM
https://forge.fi-ware.org/plugins/mediawiki/wiki/fiware/index.php/File:FI-WARE_logo.pnghttps://forge.fi-ware.org/plugins/mediawiki/wiki/fiware/index.php?title=FIWARE.OpenSpecification.Details.Cloud.DCRM&action=edit&redlink=1http://docs.openstack.org/api/api-specs.htmlhttps://forge.fi-ware.org/plugins/mediawiki/wiki/fiware/index.php/FIWARE.Glossary.Globalhttps://forge.fi-ware.org/plugins/mediawiki/wiki/fiware/index.php?title=FIWARE.Glossary.DCRM&action=edit&redlink=1
-
Future Internet Core Platform
D.4.1.3 FI-WARE GE Open Specification Page 16
3 DCRM OpenStack Open RESTful API Specification
3.1 Introduction to the DCRM OpenStack API
3.1.1 DCRM OpenStack API Core
The DCRM OpenStack API is a RESTful, resource-oriented API accessed via HTTP that uses XML-based and/or JSON-based representations for information interchange. It builds on top of the Compute, Identity, Images, and Network OpenStack API v2.0, but it extends the original specifications to provide support to additional DCRM-specific management features currently not available in OpenStack.
As in OpenStack, these APIs allow direct management of compute, network, and storage infrastructure. In addition, they have been enhanced with the following advanced management features:
Live VM migration
Host evacuation
Ongoing optimization
VM High Availability (HA)
VM Groups
Advancement placement engine (e.g., group-based anti-affinity)
Smart resource over-commit
Virtual networking
3.1.2 Intended Audience
This specification is intended for software developers aiming at interfacing their software with the DCRM. This document provides a full specification of how to manage the main entities of DCRM, which are virtual servers, virtual disks, virtual networks, virtual images, and policies.
In order to use this specifications, the reader should have a general understanding of the DCRM Generic Enabler.
To use this information, the reader should also be familiar with:
the OpenStack Compute API Specification version 2.0
the OpenStack Identity API Specification version 2.0
the OpenStack Image API Specification version 2.0
the OpenStack Network API Specification version 2.0
RESTful web services
HTTP/1.1 (RFC2616)
JSON and/or XML data serialization formats.
https://forge.fi-ware.org/plugins/mediawiki/wiki/fiware/index.php/File:FI-WARE_logo.pnghttp://docs.openstack.org/api/api-specs.htmlhttps://forge.fi-ware.org/plugins/mediawiki/wiki/fiware/index.php/FIWARE.ArchitectureDescription.Cloud.DCRMhttp://docs.openstack.org/api/openstack-compute/2/content/http://docs.openstack.org/api/openstack-identity-service/2.0/content/http://docs.openstack.org/api/openstack-image-service/2.0/content/http://docs.openstack.org/api/openstack-network/2.0/content/http://www.ietf.org/rfc/rfc2616.txthttp://www.ietf.org/rfc/rfc4627.txt?number=4627http://www.w3.org/XML/
-
Future Internet Core Platform
D.4.1.3 FI-WARE GE Open Specification Page 17
3.1.3 API Change History
This version of the DCRM OpenStack API Guide replaces and obsoletes all previous versions. The most recent changes are described in the table below:
Revision Date Changes Summary
Feb 25, 2013 R2
Apr 23, 2014 R3
3.1.4 How to Read This Document
All FI-WARE RESTful API specifications will follow the same list of conventions and will support certain common aspects. Please check Common aspects in FI-WARE Open Restful API Specifications.
For a description of the terms used along this document, see DCRM Generic Enabler.
You may also read the OpenStack API reference (v2.0)
3.1.5 Additional Resources
You can download the most current version of this document from the FI-WARE API specification selecting PDF Version from the Toolbox menu (left side), which will generate the file to download it. For more details about the DCRM Generic Enabler that this API is based upon, please refer to FI-WARE Cloud Hosting. Related documents, including an Architectural Description, are available at the same site.
3.2 General DCRM OpenStack API Information
3.2.1 Endpoints
With the aim of preserving the API separation that is part of the OpenStack architecture, the DCRM Openstack API also supports different endpoint configuration for each of the underlying APIs.
In a generic deployment, each API will have its own endpoint with the following URL template: http://{serverRoot}:{serverPort}/v2.0
For reference we will identify them in the following with these endpoints:
API Associated Endpoint
Compute http://{computeAPIserver}:{computeAPIport}/v2.0
Block Storage http://{volumeAPIserver}:{volumeAPIport}/v2.0
Identity http://{identityAPIserver}:{identityAPIport}/v2.0
Image http://{imageAPIserver}:{imageAPIport}/v2.0
https://forge.fi-ware.org/plugins/mediawiki/wiki/fiware/index.php/File:FI-WARE_logo.pnghttps://forge.fi-ware.org/plugins/mediawiki/wiki/fiware/index.php/Common_aspects_in_FI-WARE_Open_Restful_API_Specificationshttps://forge.fi-ware.org/plugins/mediawiki/wiki/fiware/index.php/Common_aspects_in_FI-WARE_Open_Restful_API_Specificationshttps://forge.fi-ware.org/plugins/mediawiki/wiki/fiware/index.php/FIWARE.ArchitectureDescription.Cloud.DCRMhttp://api.openstack.org/api-ref.htmlhttps://forge.fi-ware.eu/plugins/mediawiki/wiki/fiware/index.php/Cloud_Hosting
-
Future Internet Core Platform
D.4.1.3 FI-WARE GE Open Specification Page 18
Network http://{networkAPIserver}:{networkAPIport}/v2.0
3.2.2 Resources Summary
Each API manages a specific set of resources. With the aim of providing both conciseness and precision when describing the DCRM API, we deal with each of the underlying APIs separately. We also take a differential approach in which we describe only the changes and extensions that were made to the original APIs in order to support the advanced management features introduced by DCRM, rather than providing an extensive replication of publicly available content.
3.2.2.1 Compute API
DCRM R3 API is compatible with OpenStack Compute API (v2.0), and supports standard extensions delivered in Havana release of OpenStack, as well as specific scheduler hints outlined in the Compute API Specification section below.
The base URL is http://{computeAPIserver}:{computeAPIport}/v2.0.
3.2.2.2 Block Storage API
DCRM R3 API is compatible with OpenStack Block Storage API (v2.0). The base URL is http://{volumeAPIserver}:{volumeAPIport}/v2.0.
3.2.2.3 Network API
Release R3 of the DCRM fully supports the OpenStack Network API Specification version 2.0 with extensions specified in the Network API Specification section below.
The base URL is http://{networkAPIserver}:{networkAPIport}/v2.0.
The different Uniform Resource Identifiers (URIs) that can be used in the Network API are networks, subnets, ports, routers and floatingIPs.
3.2.3 Authentication
Each HTTP request to the DCRM OpenStack API requires the inclusion of specific authentication credentials.
The default authentication mechanism uses the OpenStack Keystone Identity API. As all FI-WARE RESTful APIs, the DCRM OpenStack API will evolve to support an authentication mechanism based on OAuth relying on the capabilities of a product in compliance with the Identity Management GE Open Specifications.
3.2.4 Representation Format
The DCRM OpenStack API supports both XML and JSON request formats. The request format is specified using the Content-Type header and is required for operations that have a request body.
https://forge.fi-ware.org/plugins/mediawiki/wiki/fiware/index.php/File:FI-WARE_logo.pnghttp://docs.openstack.org/api/openstack-compute/2/content/index.htmlhttp://docs.openstack.org/api/openstack-block-storage/2.0/content/http://docs.openstack.org/api/openstack-network/2.0/content/http://docs.openstack.org/api/openstack-network/2.0/content/
-
Future Internet Core Platform
D.4.1.3 FI-WARE GE Open Specification Page 19
The response format can be specified in requests using either the Accept header or adding an .xml or .json query extension to the request URI. If there is a conflict between Accept header and a query extension, the query extension takes precedence.
While there is no default request format, if no response format is specified, JSON is the default.
3.2.5 Resource Identification
As in the underlying OpenStack API implementations, resources are unambiguously identified by providing an ID or a URL. "When providing an ID, it is assumed that the resource exists in the current OpenStack deployment" [1]
For HTTP transport, this is made using the mechanisms described by HTTP protocol specification as defined by IETF RFC-2616.
3.2.6 Links and References
Resources often lead to refer to other resources. In those cases, we have to provide an ID or an URL to a remote resource.
In the DCRM OpenStack API, resources contain links to themselves. This allows client to avoid constructing resource URIs by composing IDs. Three link types can be associated with a resource:[2]
self link is a versioned link to the resource
bookmark link provides a permanent link to the resource
alternate link provides another URL (possibly used in another context) for
the same resource
3.2.7 Limits
Limits follow the standard specification for FI-WARE APIs Common aspects in FI-WARE Open Restful API Specifications
3.2.8 Versions
The DCRM OpenStack API uses both a URI and a MIME type versioning scheme, following the commin versioning policies adopted in all OpenStack APIs. See for instance the Openstack Compute API V2.0
3.2.9 Extensions
Extensions follow the standard specification for FI-WARE APIs Common aspects in FI-WARE Open Restful API Specifications
https://forge.fi-ware.org/plugins/mediawiki/wiki/fiware/index.php/File:FI-WARE_logo.pnghttp://docs.openstack.org/api/openstack-compute/2/content/LinksReferences.htmlhttp://docs.openstack.org/api/openstack-compute/2/content/LinksReferences.htmlhttps://forge.fi-ware.org/plugins/mediawiki/wiki/fiware/index.php/Common_aspects_in_FI-WARE_Open_Restful_API_Specificationshttps://forge.fi-ware.org/plugins/mediawiki/wiki/fiware/index.php/Common_aspects_in_FI-WARE_Open_Restful_API_Specificationshttp://docs.openstack.org/api/openstack-compute/2/content/Versions-d1e1193.htmlhttps://forge.fi-ware.org/plugins/mediawiki/wiki/fiware/index.php/Common_aspects_in_FI-WARE_Open_Restful_API_Specificationshttps://forge.fi-ware.org/plugins/mediawiki/wiki/fiware/index.php/Common_aspects_in_FI-WARE_Open_Restful_API_Specifications
-
Future Internet Core Platform
D.4.1.3 FI-WARE GE Open Specification Page 20
3.2.10 Faults
Synchronous[3] and asynchronous faults[4] are dealt with according to the common OpenStack policy
3.3 API Operations
In this section we go in depth for each operation. In order to preserve the OpenStack API organization, we also subdivide this section in compute, image, and network APIs.
3.3.1 Compute API Extensions
DCRM R3 supports standard OpenStack extensions shipped with OpenStack Havana release. Moreover, the FI-WARE Scheduler supports the following features:
host aggregates (AggregateExtraSpec filter)
availability zones
instance groups (see below)
3.3.1.1 Group Affinity Filters
When creating a VM, specify it's group with group scheduler_hints
$ nova boot --image cedef40a-ed67-4d10-800e-17455edce175 --
flavor 1 \
--hint group=foo server-1
By default, the group foo will be considered anti-affinity type. So in the above example, a VM named server-1 would not be placed with any VMs belonging to group foo. To specify affinity group, use affinity namespace (i.e. --hint group=affinity:foo). Notice that you could specify several affinity groups by stacking them in a list (i.e. --hint group=foo --hint group=foo1)
Or if you use the api:
{
'server': {
'name': 'server-1',
'imageRef': 'cedef40a-ed67-4d10-800e-17455edce175',
'flavorRef': '1'
},
'os:scheduler_hints': {
'group': 'foo'
}
}
https://forge.fi-ware.org/plugins/mediawiki/wiki/fiware/index.php/File:FI-WARE_logo.pnghttp://docs.openstack.org/api/openstack-compute/2/content/Synchronous_Faults-d1e1729.htmlhttp://docs.openstack.org/api/openstack-compute/2/content/Asynchronous_Faults-d1e2009.html
-
Future Internet Core Platform
D.4.1.3 FI-WARE GE Open Specification Page 21
{
'server': {
'name': 'server-1',
'imageRef': 'cedef40a-ed67-4d10-800e-17455edce175',
'flavorRef': '1'
},
'os:scheduler_hints': {
'group': ['foo', 'foo1']
}
}
3.3.2 Network API Extensions
Release R3 of the DCRM fully supports the OpenStack Network API Specification version 2.0, including its Layer-3 Networking Extension.
NOTE: in order to get external connectivity for VMs, the DC administrator needs to use the Neutron API and follow the Common L3 Workflow.
https://forge.fi-ware.org/plugins/mediawiki/wiki/fiware/index.php/File:FI-WARE_logo.pnghttp://docs.openstack.org/api/openstack-network/2.0/content/http://docs.openstack.org/api/openstack-network/2.0/content/http://docs.openstack.org/api/openstack-network/2.0/content/router_ext.htmlhttp://docs.openstack.org/admin-guide-cloud/content/l3_workflow.html#d6e8393
-
Future Internet Core Platform
D.4.1.3 FI-WARE GE Open Specification Page 22
4 DCRM OCCI Open RESTful API Specification
4.1 Introduction to the Open Cloud Computing Interface (OCCI) API
Please check the FI-WARE Open Specifications Legal Notice (Intel) to understand the rights to use this FI-WARE Open Specifications.
This specification is based on OCCI, published by OGF. Check the OCCI Legal Notice to understand the relevant usage rights.
OCCI is an open, standardised, extendable, RESTful interface designed to manage arbitrary resources. Whilst OCCI is used in FI-WARE to manage virtual machines, OCCI can also be used to manage storage resources, network resources, and even software services.
The OCCI walkthrough presentation provides a useful introduction to OCCI. Complete technical details of the standard are available in the formal specification documents:
OGF183: “Open Cloud Computing Interface - Core” - Describes the formal definition of the the OCCI Core Model
OGF184: “Open Cloud Computing Interface - Infrastructure” - Describes the OCCI Infrastructure extension for the IaaS domain.The document defines additional resource types, their attributes and the actions that can be taken on each resource type.
OGF185: “Open Cloud Computing Interface - RESTful HTTP Rendering” - Defines how to interact with the OCCI Core Model using the RESTful OCCI API. The document defines how the OCCI Core Model can be communicated and thus serialised using the HTTP protocol.
Any observations, feedback or questions on OCCI can be posted to the OCCI community via the OCCI Mailing list.
4.1.1 OCCI API Core
The OCCI core model forms the basis of its type system. Types made available by OCCI implementations are defined by the Category construct. There are two
specialised forms of the Category construct: Kind and Mixin. Kind defines the basic
capabilities (attributes and functionality) of a type of resource. Mixin defines a
means to further modify and extend a particular Kind’s capabilities. Action’s define
the executable functionality (e.g. methods) of either. Categories are self-descriptive, they can be discovered through a Query interface. The Query Interface allows for all service provider supported Categories to be discovered and described. The core model forms the basis for the Infrastructure as a Service specification. This specification extends the core model and it in itself provides an example of how one can extend the OCCI model to suit particular needs.
https://forge.fi-ware.org/plugins/mediawiki/wiki/fiware/index.php/File:FI-WARE_logo.pnghttps://forge.fi-ware.org/plugins/mediawiki/wiki/fiware/index.php?title=FI-WARE_Open_Specifications_Legal_Notice_(Intel)&action=edit&redlink=1http://occi-wg.org/http://www.ogf.org/http://occi-wg.org/about/legal/http://occi-wg.org/about/legal/http://dl.dropbox.com/u/165239/OCCI_walkthrough.pptxhttp://ogf.org/documents/GFD.183.pdfhttp://ogf.org/documents/GFD.184.pdfhttp://ogf.org/documents/GFD.185.pdfhttp://www.ogf.org/mailman/listinfo/occi-wghttp://ogf.org/documents/GFD.183.pdfhttp://ogf.org/documents/GFD.184.pdf
-
Future Internet Core Platform
D.4.1.3 FI-WARE GE Open Specification Page 23
4.1.2 Intended Audience
This specification is intended for both software developers and Cloud Providers. For the former, this document provides a full specification of how to interoperate with Cloud Platforms that implement the OCCI API. For the latter, this specification describes the interface to be provided in order for clients to interoperate with the Cloud Platform to provide the described functionalities. To use this information, the reader should firstly have a general understanding of the Data Centre Resource Manager Generic Enabler service. The reader should also be familiar with:
ReSTful web services.
HTTP 1.1.
Text and JSON data serialisation formats.
4.1.3 API Change History
This version of the DCRM Open RESTful API Specification replaces and obsoletes all previous versions. The most recent changes are described in the table below:
Revision Date Changes Summary
Apr 30, 2012 Initial Version
Sept 4, 2012 Updated Templated sections
April 29, 2013 Restructured content
4.1.4 How to Read This Document
It is assumed that the reader is familiar with the RESTful architectural style. This document uses the following notation:
A bold, mono-spaced font is used to represent code or logical entities, e.g., HTTP method (GET, PUT, POST, DELETE).
An italic font is used to represent document titles or some other kind of special text, e.g., URI.
For a description of some of the terms used within this document, see the Data Center Resource Management Architecture.
4.1.5 Additional Resources
OCCI walkthrough
InfoQ.com article on OCCI
OGF site
OCCI web site
OCCI mailing list
FIware Cloud Hosting Product Vision
https://forge.fi-ware.org/plugins/mediawiki/wiki/fiware/index.php/File:FI-WARE_logo.pnghttps://forge.fi-ware.eu/plugins/mediawiki/wiki/fiware/index.php/Cloud_Hosting#IaaS_DataCenter_Resource_Managementhttps://forge.fi-ware.eu/plugins/mediawiki/wiki/fiware/index.php/Cloud_Hosting#IaaS_DataCenter_Resource_Managementhttps://forge.fi-ware.eu/plugins/mediawiki/wiki/fiware/index.php/FIWARE.ArchitectureDescription.Cloud.DCRMhttps://forge.fi-ware.eu/plugins/mediawiki/wiki/fiware/index.php/FIWARE.ArchitectureDescription.Cloud.DCRMhttp://dl.dropbox.com/u/165239/OCCI_walkthrough.pptxhttp://infoq.com/articles/open-interoperable-cloudhttp://www.ogf.org/http://occi-wg.org/http://www.ogf.org/mailman/listinfo/occi-wghttps://forge.fi-ware.eu/plugins/mediawiki/wiki/fiware/index.php/Cloud_Hosting
-
Future Internet Core Platform
D.4.1.3 FI-WARE GE Open Specification Page 24
4.2 General OCCI API Information
4.2.1 Resources Summary
To understand what infrastructural resources are specified by OCCI see GFD184. To understand the core resource model within OCCI see GFD183 Sections 3 and 4. As providers of the API may wish to use different URI schemes and hierarchies, OCCI does not prescribe a static configuration. To understand how the hierarchy can be discovered through OCCI’s query interface see GFD183. The OCCI Query Interface is advertised using the well-known location IETF RFC5785. OCCI is highly extensible and various extension mechanisms and extension points are documented in GFD183 Section 4.6.
4.2.2 Authentication
Each HTTP request against OCCI requires the inclusion of specific authentication credentials. The specific implementation of this API may support multiple authentication schemes (OAuth, Basic Auth, Token) as such mechanisms are orthogonal to the API. This will be determined by the specific provider that implements the GE. Please contact with it to determine the best way to authenticate against this API. Remember that some authentication schemes may require that the API operate using SSL over HTTP (HTTPS). See GFD185 for further details.
4.2.3 Representation Format
The OCCI API supports plain text:
text/plain - this is the default content type
text/occi
text/uri-list
See GFD185 for precise Augmented Backus-Naur Form (ABNF) specifications of these content types. JSON support is currently being developed. The request format is specified using the Content-Type header and is required for operations that have a request body. The response format can be specified in requests using the standard
HTTP Accept header.
4.2.4 Representation Transport
Resource representation is transmitted between client and server by using HTTP 1.1 protocol, as defined by IETF RFC–2616. Each time an HTTP request contains payload, a Content-Type header shall be used to specify the MIME type of wrapped representation. In addition, both client and server may use as many HTTP headers as they consider necessary. For OCCI specifics see GFD185.
4.2.5 Resource Identification
To understand how resource identification is achieved in OCCI, see GFD183.
https://forge.fi-ware.org/plugins/mediawiki/wiki/fiware/index.php/File:FI-WARE_logo.pnghttp://ogf.org/documents/GFD.184.pdfhttp://ogf.org/documents/GFD.183.pdfhttp://ogf.org/documents/GFD.183.pdfhttp://tools.ietf.org/html/rfc5785http://ogf.org/documents/GFD.183.pdfhttp://ogf.org/documents/GFD.185.pdfhttp://ogf.org/documents/GFD.185.pdfhttp://ogf.org/documents/GFD.185.pdfhttp://ogf.org/documents/GFD.183.pdf
-
Future Internet Core Platform
D.4.1.3 FI-WARE GE Open Specification Page 25
4.2.6 Linking Resources
Resources often lead to refer to other resources. To review how this is done in OCCI
(using the Link construct), see GFD183 Section 4.5.3 and GFD184 on their
application to infrastructural resources.
4.2.7 Pagination of Resource Collections
This is being developed through the JSON specification.
4.2.8 API Limits
This is implementation specific. In the OpenStack OCCI implementation, within the
nova-api module, a WSGI middleware is included to enable rate limiting. The OCCI
API can also use this and as such be part of its middleware pipeline as is done for all
OpenStack API services. This is configured through the /etc/nova/api-paste.ini
file.
4.2.9 Versions
To get the version that an OCCI service is using, see GFD185. Associated semantics with version mismatches etc are also dealt with there.
4.2.10 Extensibility
See GFD183 and GFD184. It should be noted that GFD184 is an extension itself and so offers a comprehensive example OCCI extensibility. The CompatibleOne project uses OCCI as their core model. How they extend the OCCI core model can be seen in the CORDS reference manual.
4.2.11 Faults
For the full set of faults that an OCCI service can return please also see GFD185. The most common error codes are listed here:
HTTP Return code
Description
200 OK Indicates that the request was successful. The response MUST contain the created resource instance's representation.
201 OK Indicates that the request was successful. The response MUST contain a HTTP Location header to the newly created resource instance.
400 Bad Request
Used to signal parsing errors or missing information (e.g. an attribute that is required is not supplied in the request).
401 Unauthorized
The client does not have the required permissions/credentials.
404 Not Found Used to signal that the request had information (e.g. a kind, mixin,
https://forge.fi-ware.org/plugins/mediawiki/wiki/fiware/index.php/File:FI-WARE_logo.pnghttp://ogf.org/documents/GFD.183.pdfhttp://ogf.org/documents/GFD.184.pdfhttp://ogf.org/documents/GFD.185.pdfhttp://ogf.org/documents/GFD.183.pdfhttp://ogf.org/documents/GFD.184.pdfhttp://ogf.org/documents/GFD.184.pdfhttp://www.compatibleone.org/http://compatibleone.org/bin/download/Docs/WebHome/CordsReferenceManualV2.03.pdfhttp://ogf.org/documents/GFD.185.pdf
-
Future Internet Core Platform
D.4.1.3 FI-WARE GE Open Specification Page 26
action, attribute, location) that was unknown to the service and so not found.
500 Internal Server Error
The state before the request should be maintained in such an error condition. The implementation MUST roll-back any partial changes made during the erroneous execution.
4.3 API Operations
See GFD183, GFD184 and GFD185 for all OCCI specifications on specific aspects. The FI-WARE programmer guide will also provide examples of how to use the API. Only operations related to OCCI extensions will be discussed and described here. In the sections below a summary of the extension, its purpose and example usage will
be given. The example usages will use the text/occi content type for brevity.
4.4 Architectural Operation Mapping
These operations are listed in the Data Centre Resource Management architectural specification. A high level mapping of these operations to OCCI requests are presented below. The operations described here are all listed with mandatory inputs.
createVirtualServer
o Description: provision a new virtual server with the given properties (virtual hardware, policy parameters, access, etc). Returns unique ID of the virtual server.
o OCCI Mapping: A HTTP POST using the compute, OsTemplate
and ResourceTemplate categories.
destroyVirtualServer
o Description: remove a virtual server o OCCI Mapping: A HTTP DELETE issued against the HTTP URL
identifying the virtual server instance.
powerOnVirtualServer
o Description: turn on a virtual server
o OCCI Mapping: A HTTP POST using the start action.
createVirtualServer
o Description: provision a new virtual server with the given properties (virtual hardware, policy parameters, access, etc). Returns unique ID of the virtual server.
o OCCI Mapping: A HTTP POST using the compute, OsTemplate
and ResourceTemplate categories.
destroyVirtualServer
o Description: remove a virtual server o OCCI Mapping: A HTTP DELETE issued against the HTTP URL
identifying the virtual server instance.
powerOnVirtualServer
o Description: turn on a virtual server
o OCCI Mapping: A HTTP POST using the start action.
https://forge.fi-ware.org/plugins/mediawiki/wiki/fiware/index.php/File:FI-WARE_logo.pnghttp://ogf.org/documents/GFD.183.pdfhttp://ogf.org/documents/GFD.184.pdfhttp://ogf.org/documents/GFD.185.pdfhttps://forge.fi-ware.eu/plugins/mediawiki/wiki/fiware/index.php/Cloud_Hosting#IaaS_DataCenter_Resource_Managementhttps://forge.fi-ware.eu/plugins/mediawiki/wiki/fiware/index.php/Cloud_Hosting#IaaS_DataCenter_Resource_Management
-
Future Internet Core Platform
D.4.1.3 FI-WARE GE Open Specification Page 27
powerOffVirtualServer
o Description: turn off a virtual server
o OCCI Mapping: A HTTP POST using the stop action,
parameterised with the method=acpioff.
restartVirtualServer
o Description: restart a virtual server
o OCCI Mapping: A HTTP POST using the restart action.
shutdownVirtualServer
o Description: shut down a virtual server (note: the ability to perform this operation on the fly depends on the capabilities of the underlying virtualisation platform)
o OCCI Mapping: A HTTP POST using the stop action,
parameterised with the method=graceful.
resizeVirtualServer
o Description: change the virtual hardware allocation for a virtual server (note: the types of resources for which the reconfiguration can be done on the fly depends on the capabilities of the underlying virtualization platform)
o OCCI Mapping: A HTTP POST (partial update) against the the HTTP URL identifying the virtual server instance and with the
ResourceTemplate specified indicating the new hardware allocation
profile.
getVirtualServerDetails
o Description: returns details of a virtual server (virtual hardware specification, state, associated policy parameters, access details, etc)
o OCCI Mapping: A HTTP GET against the the HTTP URL identifying the virtual server instance.
createVirtualDisk
o Description: provision a new virtual disk with the given properties (size, capabilities, etc). Returns unique ID of the virtual disk.
o OCCI Mapping: A HTTP POST using the storage category.
destroyVirtualDisk
o Description: remove a virtual disk o OCCI Mapping: A HTTP DELETE issued against the HTTP URL
identifying the virtual disk instance.
attachVirtualDisk
o Description: attach 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)
o OCCI Mapping: A HTTP POST using the storagelink link
category.
detachVirtualDisk
o Description: detach 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)
https://forge.fi-ware.org/plugins/mediawiki/wiki/fiware/index.php/File:FI-WARE_logo.png
-
Future Internet Core Platform
D.4.1.3 FI-WARE GE Open Specification Page 28
o OCCI Mapping: A HTTP DELETE issued against the HTTP URL identifying the storage link associating the virtual server with the virtual disk instances.
getVirtualDiskDetails
o Description: return details of a given virtual disk (ID, capabilities, attachment details, etc)
o OCCI Mapping: A HTTP GET against the the HTTP URL identifying the virtual disk instance.
createVirtualNetwork
o Description: provision a new virtual network with the given properties (e.g., VLAN ID, capabilities, etc). Returns unique ID of the virtual network.
o OCCI Mapping: A HTTP POST using the network and
ipnetwork categories.
destroyVirtualNetwork
o Description: remove a virtual network o OCCI Mapping: A HTTP DELETE issued against the HTTP URL
identifying the virtual network instance.
attachVirtualServerToNetwork
o Description: attach a virtual network interface of a given virtual server to a given virtual network
o OCCI Mapping: A HTTP POST using the networkinterface link
category and ipnetworkinterface mixin.
detachVirtualServerFromNetwork
o Description: detach a virtual network interface of a given virtual server from a given virtual network
o OCCI Mapping: A HTTP DELETE issued against the HTTP URL identifying the network link associating the virtual server with the virtual network instances.
getVirtualNetworkDetails
o Description: return details of a given virtual network (ID, capabilities, attachment details, etc)
o OCCI Mapping: A HTTP GET against the the HTTP URL identifying the virtual network instance.
listVirtualImages
o Description: return a list of all available virtual images (visible by the authenticated user)
o OCCI Mapping: HTTP GET on the Query Interface
queryVirtualImages
o Description: return a list of available virtual images, filtered by given query criteria.
o OCCI Mapping: HTTP GET on the Query Interface with a categories filter applied.
getVirtualImageDetails
o Description: return details of a virtual image (type, size, creation details, etc)
https://forge.fi-ware.org/plugins/mediawiki/wiki/fiware/index.php/File:FI-WARE_logo.png
-
Future Internet Core Platform
D.4.1.3 FI-WARE GE Open Specification Page 29
o OCCI Mapping: image details are present in all HTTP GETs on the Query Interface.
uploadVirtualImage
o Description: upload a new virtual image into the virtual image repository
o OCCI Mapping: HTTP POST against the query interface with the
OsTemplate category supplied (Note not currently supported in OCCI
V1.1).
4.4.1 OCCI Kind Extensions
These extensions extend the OCCI core model Kind construct (See Core Model
Section 4.4.2). As such they can have full create, retrieve, update and delete functionality.
4.4.2 Security Group Extension
Security Rules are associated with a Collection defined by a Mixin. Rules can be removed likewise. The semantics of this are set out in the OCCI Core Model
document Section 4.6.3, where user-supplied Mixins are described. This is a
candidate extension to be offered to OCCI for inclusion in main spec.
term: USER_DEFINED
scheme: USER_DEFINED
rel: http://schemas.ogf.org/occi/infrastructure/security#group
Example Text Rendering:
Category: my_grp; scheme="http://www.mystuff.org/sec#";
class="mixin";
rel="http://schemas.ogf.org/occi/infrastructure/security#group
4.4.3 Security Rule Extension
Using this extension network security ingress rules can be applied to VMs. The definition of such rules are a requirement in satisfying NIST cloud computing SAJACC use cases. EC2, OpenStack and OpenNebula all share this functionality. This is a candidate extension to be offered to OCCI for inclusion in main spec.
term: rule
scheme: http://schemas.openstack.org/occi/infrastructure/network/securi
ty#
attributes:
o occi.network.security.protocol: enumeration of strings,
range: tcp, ip, icmp
o occi.network.security.to: integer, range: 0–65535
o occi.network.security.from: integer, range: 0–65535
o occi.network.security.range: CIDR string
https://forge.fi-ware.org/plugins/mediawiki/wiki/fiware/index.php/File:FI-WARE_logo.pnghttp://ogf.org/documents/GFD.183.pdfhttp://ogf.org/documents/GFD.183.pdfhttp://ogf.org/documents/GFD.183.pdfhttp://schemas.ogf.org/occi/infrastructure/security#grouphttp://schemas.openstack.org/occi/infrastructure/network/securityhttp://schemas.openstack.org/occi/infrastructure/network/securityhttp://en.wikipedia.org/wiki/Classless_Inter-Domain_Routing
-
Future Internet Core Platform
D.4.1.3 FI-WARE GE Open Specification Page 30
Example text rendering:
Category: rule;
scheme="http://schemas.openstack.org/occi/infrastructure/netwo
rk/security#"; class="kind"
X-OCCI-Attribute: occi.network.security.protocol = "tcp"
X-OCCI-Attribute: occi.network.security.to = 22
X-OCCI-Attribute: occi.network.security.from = 22
X-OCCI-Attribute: occi.network.security.range = "0.0.0.0/24"
4.4.4 VNC Console Extension
This extension is used only to relay information back to the client about console
endpoint information. It only supports HTTP GET or retrieve functionality.
term: vnc_console
scheme: http://schemas.openstack.org/occi/infrastructure/compute#
attributes:
o org.openstack.compute.console.vnc: URI string
Example text rendering:
Category: vnc_console;
scheme="http://schemas.openstack.org/occi/infrastructure/compu
te#"; class="mixin"
X-OCCI-Attribute:
org.openstack.compute.console.vnc="http://10.234.54.23:5901"
4.4.5 SSH Console Extension
This extension is used only to relay information back to the client about console
endpoint information. It only supports HTTP GET or retrieve functionality.
term: ssh_console
scheme: http://schemas.openstack.org/occi/infrastructure/compute#
attributes:
o org.openstack.compute.console.ssh: URI string
Example text rendering:
Category: ssh_console;
scheme="http://schemas.openstack.org/occi/infrastructure/compu
te#"; class="mixin"
X-OCCI-Attribute:
org.openstack.compute.console.ssh="ssh://142.123.45.42:22"
https://forge.fi-ware.org/plugins/mediawiki/wiki/fiware/index.php/File:FI-WARE_logo.pnghttp://schemas.openstack.org/occi/infrastructure/computehttp://schemas.openstack.org/occi/infrastructure/compute
-
Future Internet Core Platform
D.4.1.3 FI-WARE GE Open Specification Page 31
4.4.6 OCCI Mixin Extensions
These extensions extend the OCCI core model Mixin construct (See Core Model
Section 4.4.3). As such they can only have full create and delete functionality.
4.4.7 TCP - Trusted Compute Pool Extension
This mixin extension signals to the backend implementation that the requested VM to be provisioned should be placed on hardware that has TCP capabilities.
term: tcp
scheme: http://schemas.fi-ware.eu/occi/infrastructure/compute#
attributes:
o eu.fi-ware.compute.tcp: boolean
Example text rendering:
Category: floating_ip;
scheme="http://schemas.openstack.org/instance/network#";
class="mixin"
X-OCCI-Attribute:
org.openstack.credentials.publickey.name="my_pub_key"
4.4.8 Administrative Password Extension
This mixin extension allows for authenticated users to specify the administrative password of the VM.
term: admin_pwd
scheme: http://schemas.openstack.org/instance/credentials#
attributes:
o org.openstack.credentials.admin_pwd: string
Example text rendering:
Category: admin_pwd;
scheme="http://schemas.openstack.org/instance/credentials#";
class="mixin"
X-OCCI-Attribute:
org.openstack.credentials.admin_pwd="pussinboots"
4.4.9 Access IP Extension
This mixin extension allows for authenticated users to specify an additional access IP and is used as a means to route from that IP to the target VM’s internal IP.
term: access_ip
scheme: http://schemas.openstack.org/instance/network#
attributes:
o org.openstack.network.access.ip: string
https://forge.fi-ware.org/plugins/mediawiki/wiki/fiware/index.php/File:FI-WARE_logo.pnghttp://ogf.org/documents/GFD.183.pdfhttp://schemas.fi-ware.eu/occi/infrastructure/computehttp://schemas.openstack.org/instance/credentialshttp://schemas.openstack.org/instance/network
-
Future Internet Core Platform
D.4.1.3 FI-WARE GE Open Specification Page 32
o org.openstack.network.access.version: enumeration of
strings, range: ipv4, ipv6
Example text rendering:
Category: access_ip;
scheme="http://schemas.openstack.org/instance/network#";
class="mixin"
X-OCCI-Attribute:
org.openstack.network.access.ip="188.12.132.58"
X-OCCI-Attribute: org.openstack.network.access.version="ipv4"
4.4.10 Key Pair Extension
This mixin extension allows for authenticated users to set a SSH public key for passwordless authentication (via SSH) against the provisioned VM.
term: public_key
scheme: http://schemas.openstack.org/instance/credentials#
attributes:
o org.openstack.credentials.publickey.name: string
o org.openstack.credentials.publickey.data: string
Example text rendering:
Category: floating_ip;
scheme="http://schemas.openstack.org/instance/network#";
class="mixin"
X-OCCI-Attribute:
org.openstack.credentials.publickey.name="my_pub_key"
X-OCCI-Attribute:
org.openstack.credentials.publickey.datap="ssh-dss
AAAAB3NzaC1kc3MAAACBAML/WvvbXBF1DWTou0ISmDJGo4OsfU6qW94vyZuiM0
5LbChnPrBVlzv1p2gWw/PlC6jkD/aNaMJwbuQoS/1J2G6cHgcX6oeNM+mo/BtH
KZGUmMjvKeeNuP8BqB0YX4OMSQ5E0GLfFmLC0P4QpjZ0jiuE4K8AM3Ht75p9XC
tdTpF3AAAAFQC6E882UjUeZGbv8zja97gfFbLTGwAAAIBERL187u5siYAf2Cq4
pBZ3YSoeWjrn68bU5h9DWXlRnMb1G0waPhh4MCbYfKefqstu/mwuq9w2gIGYuz
Y2NBHX2BYDtC2cfKh0v1SzFv1U6UtOg9WT34eNuHNkCrgE1p+JuSaZQ8rO864G
abxwSWxMQe53DwpaznCzcuK6KL4VGQAAAIBybl3bv7S1UsW51LmnasshlVVaMF
5i1pS5qFYjK829"
4.4.11 Floating IP Extension
This mixin extension allows for authenticated users know what the allocated floating IP address of a VM is.
term: floating_ip
scheme: http://schemas.openstack.org/instance/network#
attributes:
o org.openstack.network.floating.ip: valid IP address
rendered as string
https://forge.fi-ware.org/plugins/mediawiki/wiki/fiware/index.php/File:FI-WARE_logo.pnghttp://schemas.openstack.org/instance/credentialshttp://schemas.openstack.org/instance/network
-
Future Internet Core Platform
D.4.1.3 FI-WARE GE Open Specification Page 33
Example text rendering:
Category: floating_ip;
scheme="http://schemas.openstack.org/instance/network#";
class="mixin"
X-OCCI-Attribute:
org.openstack.network.floating.ip="172.156.89.12"
4.4.12 OCCI Action Extensions
These extensions extend the OCCI core model Action construct (See Core Model
Section 4.5.4). As such they only implement the executive aspect of the construct
(via HTTPPOST`).
4.4.13 Change Password Action Extension
This action allows authenticated users to change the administrative user’s password.
term: chg_pwd
scheme: http://schemas.openstack.org/instance/action#
attributes:
o org.openstack.credentials.admin_pwd: string
Example text rendering:
Category: chg_pwd;
scheme="http://schemas.openstack.org/instance/action#";
class="action"
X-OCCI-Attribute:
org.openstack.credentials.admin_pwd="new_pass"
4.4.14 Revert Action Extension
This action allows authenticated users to rollback a VM resize operation.
term: revert_resize
scheme: http://schemas.openstack.org/instance/action#
attributes: None
Example text rendering:
Category: revert_resize;
scheme="http://schemas.openstack.org/instance/action#";
class="action"
4.4.15 Confirm Resize Action Extension
This action allows authenticated users to confirm that a VM resize operation was successful and met their needs.
term: confirm_resize
scheme: http://schemas.openstack.org/instance/action#
https://forge.fi-ware.org/plugins/mediawiki/wiki/fiware/index.php/File:FI-WARE_logo.pnghttp://ogf.org/documents/GFD.183.pdfhttp://schemas.openstack.org/instance/actionhttp://schemas.openstack.org/instance/actionhttp://schemas.openstack.org/instance/action
-
Future Internet Core Platform
D.4.1.3 FI-WARE GE Open Specification Page 34
attributes: None
Example text rendering:
Category: confirm_resize;
scheme="http://schemas.openstack.org/instance/action#";
class="action"
4.4.16 Create Image Action Extension
In order to create a bootable VM image from an existing running VM, a user can use
the create_image Action. The resultant image MUST and will be exposed only to the
owning user through the OCCI query interface.
term: create_image
scheme: http://schemas.openstack.org/instance/action#
attributes:
o org.openstack.snapshot.image_name: string
Example text rendering:
Category: create_image;
scheme="http://schemas.openstack.org/instance/action#";
class="action"
X-OCCI-Attribute:
org.openstack.snapshot.image_name="my_image_name"
4.4.17 Allocate IP Action Extension
This action allows authenticated users to allocate a floating (static) IP to a VM. The pools (pool names are obtained from the Query Interface) from which IPs can be obtained is listed in the OCCI Query Interface.
term: alloc_float_ip
scheme: http://schemas.openstack.org/instance/action#
attributes:
o org.openstack.network.floating.pool: string
Example text rendering:
Category: alloc_float_ip;
scheme="http://schemas.openstack.org/instance/action#";
class="action"
X-OCCI-Attribute: org.openstack.network.floating.pool="nova"
4.4.18 Deallocate IP Action Extension
This action allows authenticated users to deallocate a floating (static) IP to a VM and release back to the originating IP pool.
term: dealloc_float_ip
scheme: http://schemas.openstack.org/instance/action#
https://forge.fi-ware.org/plugins/mediawiki/wiki/fiware/index.php/File:FI-WARE_logo.pnghttp://schemas.openstack.org/instance/actionhttp://schemas.openstack.org/instance/actionhttp://schemas.openstack.org/instance/action
-
Future Internet Core Platform
D.4.1.3 FI-WARE GE Open Specification Page 35
attributes: None
Example text rendering:
Category: dealloc_float_ip;
scheme="http://schemas.openstack.org/instance/action#";
class="action"
https://forge.fi-ware.org/plugins/mediawiki/wiki/fiware/index.php/File:FI-WARE_logo.png
-
Future Internet Core Platform
D.4.1.3 FI-WARE GE Open Specification Page 36
5 FIWARE OpenSpecification Cloud SelfServiceInterfaces
5.1 Preface
Within this document you find a self-contained open specification of a FI-WARE generic enabler, please consult as well the FI-WARE_Product_Vision, the website on http://www.fi-ware.org and similar pages in order to understand the complete context of the FI-WARE project.
5.2 Copyright
Copyright © 2013 by UPM. All Rights Reserved.
5.3 Legal Notice
Please check the following Legal Notice to understand the rights to use these specifications.
5.4 Overview
This specification describes the Self Service Interfaces GE which is enabler for user/admin to better interact with the cloud infrastructure. The main goal of the Self Service Interfaces is to provide a user interface and libraries as a support for the administrators and the users to easily manage their services deployed in the Fi-Ware cloud. This GE consist of several components that permit to that enable to perform the following actions: Create/Delete/Edit Image/Flavor/Project/User/Snapshots/Volumes/Containers/Objects, Create/Terminate/Reboot/Resize/Delete Instance etc.
5.4.1.1 GE Description
The Self Services Interfaces is divided in two parts: User Portal and Toolkit.
The User Portal is implemented in a form of a Web GUI following the example of the portals that today's common cloud infrastructure managers like Amazon EC2, Eucalyptus,Cloud Sigma, Rackspace, etc. have. In concrete it bases its design principles on the OpenStack Horizon Dashboard. The basic objective of the user portal is to facilitate the user of the cloud perform operations over the underlying infrastructure. This includes perform actions such as: create user, manage projects, lunch instances on a base of images, create images in the image repository, retrieve flavors from the resource, etc. Moreover the portal facilitates management of a Virtual Data centers (VDCs), Services and Service Data Centers (SDCs), PaaS management and will offer monitoring statistics of the physical and virtual machines. The Toolkit is aimed for administrators and experienced users and it consist of various scripts that permit to perform the same actions the user portal does and some more advanced options.
https://forge.fi-ware.org/plugins/mediawiki/wiki/fiware/index.php/File:FI-WARE_logo.pnghttps://forge.fi-ware.org/plugins/mediawiki/wiki/fiware/index.php/FI-WARE_Product_Visionhttp://www.fi-ware.org/https://forge.fi-ware.org/plugins/mediawiki/wiki/fiware/index.php/UPMhttps://forge.fi-ware.org/plugins/mediawiki/wiki/fiware/index.php/FI-WARE_Open_Specifications_Legal_Notice
-
Future Internet Core Platform
D.4.1.3 FI-WARE GE Open Specification Page 37
5.4.1.2 GE Components
The following diagram shows the main components of the Self Service Interfaces GE, as well as their main interactions.
Figure: Self Service Interfaces GE
5.4.1.2.1 User Portal
A web client-side application implemented in JavaScript, that follows the structure as the OpenStack Horizon component, but has extended functionality to meet the requirements of the SM GE components. It is a Backbone-based application that follows the (Model-View-Controller) MVC design principles and aims at improving the user experience by using AJAX. The portal uses the underlying Cloud Library.
5.4.1.2.2 Toolkit
A direct command line interface to the cloud infrastructure and platform aimed for experienced users. The toolkit uses the cloud library and its different APIs to perform different calls to the SM GE, DCRM GE, Object Storage GE, Keystone/IdM GE and Monitoring GE.
5.4.1.2.3 Cloud Library
This library consist of sub-libraries developed in JavaScript. Each of them implement specific APIs to enable the use of the underlying GE from the User Portal or with the Toolkit.
https://forge.fi-ware.org/plugins/mediawiki/wiki/fiware/index.php/File:FI-WARE_logo.pnghttps://forge.fi-ware.org/plugins/mediawiki/wiki/fiware/index.php/File:Self_Service_Interfaces_GE_Architecture_GE.png
-
Future Internet Core Platform
D.4.1.3 FI-WARE GE Open Specification Page 38
5.5 Basic Design Principles
The User Portal design has the following key features:
Client side app accessible within an HTML5 Page (no Web server is needed to interact with back-end)
Internationalization: i18n (supports currently 4 languages)
Responsive design: adaptable to multiple device screens (desktop, smartphone, tablet, etc)
Customizable Object Oriented CSS
Dynamic web app refreshed automatically as backend changes
The Toolkit contains Node.js based scripts as a JavaScript implementation of different APIs. The Cloud Library comprises of libraries that contain various JavaScript APIS: OpenStack APIs, OpenStack API extensions, CDMI APIs and Monitoring APIs. Each of these APIs are organized in the following libraries: ovf, sdc, jstack, cdmi and the monitoring library.
5.5.1 References
[Keystone] Open Stack Keystone. http://keystone.openstack.org, 2012
[Dashboard] Open Stack Dashboard. http://wiki.openstack.org/OpenStackDashboard, 2012
[Glance] Open Stack Glance image repository documentation. http://glance.openstack.org, 2012
[Amazon EC2]
Amazon Management Console. http://aws.amazon.com/console, 2012
[Eucalyptus] Eucalyptus web-based front-end. http://open.eucalyptus.com/wiki/EucalyptusManagement_v1.5, 2012
[Rackspace] Rackspace control panel. http://en.wikipedia.org/wiki/File:Rackspace_Cloud_control_panel_screenshot.png
[Cloud Sigma]
Cloud Sigma web interface. http://cloudsigma.com/en/platform-details/intuitive-web-interface, 2012
5.6 Re-utilised Technologies/Specifications
The Self Service Interfaces GE is based on RESTful Design Principles. The technologies and specifications used in this GE are:
RESTful web services
HTTP/1.1 (RFC2616)
JSON and XML data serialization formats.
https://forge.fi-ware.org/plugins/mediawiki/wiki/fiware/index.php/File:FI-WARE_logo.pnghttp://keystone.openstack.org/http://wiki.openstack.org/OpenStackDashboardhttp://glance.openstack.org/http://aws.amazon.com/consolehttp://open.eucalyptus.com/wiki/EucalyptusManagement_v1.5http://en.wikipedia.org/wiki/File:Rackspace_Cloud_control_panel_screenshot.pnghttp://cloudsigma.com/en/platform-details/intuitive-web-interfacehttp://cloudsigma.com/en/platform-details/intuitive-web-interfacehttp://www.ietf.org/rfc/rfc2616.txt
-
Future Internet Core Platform
D.4.1.3 FI-WARE GE Open Specification Page 39
OpenStack Compute API v2.0
5.7 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 helpful 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 FI-WARE level, please refer to FI-WARE Global Terms and Definitions
Runtime Execution Container (REC) -- a VM with all the software stack required to deploy a complete node in an application architecture. It usually comprises one or more VMs, middleware, monitoring probes, and Chef client and SDC agent to support installation and configuration.
Software Deployment and Configuration GE (SDC GE) -- a GE in devoted to the automated installation and configuration of software on VMs through the execution of recipes in the corresponding nodes. It relies on Opscode Chef technology.
Software Deployment and Configuration Interface (SDCI) -- the interface offered by the SDC GE to be managed by the PaaS Manager or a Cloud Portal.
Product Instance (PI) -- an installed software in a VMs, usually referring to middleware or platform software (E.g.: Apache Tomcat, MySQL, etc.).
Application Component (AC) -- a component (or configuration artifact) that implements usually one or more components of an application architecture. These ACs are installed on, and differentiated from, existing PIs.
PaaS Manager Interface (PMI) -- the interface offered by the PaaS Manager GE to be used by a Cloud Portal to manage both the catalogue and the lifecycle of the platform resources and applications.
https://forge.fi-ware.org/plugins/mediawiki/wiki/fiware/index.php/File:FI-WARE_logo.pnghttp://docs.openstack.org/api/openstack-compute/2/content/index.htmlhttps://forge.fi-ware.org/plugins/mediawiki/wiki/fiware/index.php/FIWARE.Glossary.Global
-
Future Internet Core Platform
D.4.1.3 FI-WARE GE Open Specification Page 40
6 FIWARE OpenSpecification Cloud ObjectStorage
6.1 Preface
Within this document you find a self-contained open specification of a FI-WARE generic enabler, please consult as well the FI-WARE_Product_Vision, the website on http://www.fi-ware.org and similar pages in order to understand the complete context of the FI-WARE project.
6.2 Copyright
The FI-WARE ObjectStorage Specification is Copyright © 2014 INTEL. Please note that this specification adopts the CDMI standard, which is published by and copyright SNIA.
6.3 Legal Notice
Please check the following Legal Notice to understand the rights to use these specifications.
6.4 Overview
Object Storage is one of the Generic Enablers within FI-WARE. It offers persistent storage for digital objects, important cloud-based functionality that has been specifically requested by Use Cases. Objects