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.AppManagement - FIWARE Forge Wiki


From FIWARE Forge Wiki

Jump to: navigation, search
Name FIWARE.OpenSpecification.Cloud.AppManagement
Chapter Cloud,
Catalogue-Link to Implementation Murano
Owner Telefónica I+D, Fernando López Aguilar, Henar Muñoz Frutos

If you need to check out the Open Specs of the previous FIWARE Release (Release 4) you can go to FIWARE.OpenSpecification.Cloud.AppManagement 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.


This specification describes the Cloud Application Management Service GE, which is a key enabler to deploy FIWARE Generic enablers on top of OpenStack.

The Application Management Service GE provides the basic support for hardware deployment management (virtual servers, networks...) and software installation management. This includes both application provisioning phase and on going life-cycle management of applications. The end user will be able to deploy applications including their hardware and their software. The application management services interacts with the Compute service, Image service, and Networking service (which belong to the IaaS GE) by using the Orchestrator service in order to manage the whole infrastructure.

The baseline for the Application Management Service GE is OpenStack Murano Service. Hence, the Application Management Service introduces an application catalog to OpenStack, enabling application developers and cloud administrators to publish various cloud-ready applications in a browsable categorized catalog.

The main capabilities provided for a application management user are:

  • The existence of a application Catalogue, which includes all the software to be instantiated.
  • Deployment of complex application configurations, including hardware and software, in terms of blueprint templates
  • Manage the life cycle of the application

Application Management Service features

The Application Management Service contains the following main features:

  • The application management service contains a catalog which provide a way to publish applications, including deployment rules and requirements, suggested configuration, output parameters and billing rules. The application catalog is a place to find and self-provision third-party applications and services, integrate them into their environment, and track usage information and costs.
  • The application management service allows for the deployment on the application on top of the Cloud, including both the infrastructure and the application itself.
  • The management of applications already deployed into the Cloud.

With respect to the OpenStack Murano baseline, the Application Management Service provides in addition the following set of high-level advanced features:

different layers such as DB, web server and others, which implies the deployment of software not just in an unique VM but in several ones. The environment template is the specification of the set of VMs plus the applications to be installed on top of. The user can define environment templates from scratch or reuse and customize them (e.g. including keypairs). Environment templates not only cover instantiation, but also the specification of such templates, store them in a catalogue and clone them from the abstract template catalog. In this way, an abstract environment template catalogue as well as a environment template one will be stored in the database, storing templates shared among all users and individual ones.

deployment installations instructions are specified in configuration languages (puppet, chef). In order to reuse this community, some adaptors (chef adaptor and puppet adaptor) are required in the VM side. Both chef and puppet recipes will not be managed by centralized server (chef-server, puppet-master) but they will use the standalone version, concretely the usage of chef-solo and puppet apply.

Basic Concepts


The main entities considered in the Application Management are:

  • Environment - A logical entity for grouping applications into a single deployment.
  • Template - The specification of an environment which is stored in a catalogue.
  • Application - A software component that has its own configuration and deployment scripts. An application may use multiple VMs for deployment, such as a Galera cluster or a SQL Cluster, for example.
  • Application definition - A description of an application, which includes metadata describing how the application is to be deployed, application requirements, the application UI and so on.

The key concepts visible to the cloud user are:

  • API service - Used by the UI, the API enables administrators to manipulate application metadata, developers to publish and manage application, and end-users to perform application configuration and self-provisioning.
  • Engine - This module is in charge of processing all the requests from the API interacting with the rest of Infrastructure services.
  • Agent - There is an agent inside the VMs which is in charge of processing all the software instructions.


The interfaces are:

  • Northbound interface. The Application Management GE offers an interface to its users to manage environments and applications (in the picture it correponds to the interface where the dashboard accesses to the Application Management service). This interface is specified in Murano API.
  • Southbound interfaces. The Application Management implementation of the enabler invokes the Cloud infrastructure by the Heat Orchestrator API. In addition, there is an interaction among Application Manager and Virtual Machines, which is done by a message service.


The mission for this project is to provide a way to make third-party applications and services running on VMs or even external services available as self-service for OpenStack. These applications may be a simple, a single VM or complex, multi tier applications with autoscaling and self healing.

The figure below shows the architecture of the Application Management Service. The Application Management API will expose API calls to manage (CRUD) services available for deployment. This API will be used by the dashboard or by Client Command line for the deployment of applications. The API module sends to the engine module the requests to be executed. These requests requires the interaction with other Infrastructure services by using the Orchestration service, which in case of OpenStack it is used OpenStack Orchestration Service (Heat). Finally, the deployed VMs, contains an application agent which is in charge of pressing the software instructions.

Application Management Service
Application Management Service

Example Scenario

The Application Management Service is involved in three different phases:

  • Management of the environment templates.
  • Deployment of applications.

Environment Template Management

The management of environments templates involves several operations that have to do the configuration and provisioning of the resources required for the deployment of applications.

First of all, the environments template have to be defined. The definition of an environment includes the specification of the products that will be supported. This functionality is related to the capacities of the Application Management Software Catalogue, that is, the list of products that can be actually installed, configured and used. Therefore, the definition of environments involves the specification of products and their supported releases as well as the specification of the hadware where it is going to be deployed.

Secondly, in order to enable the deployment of applications, an environment template has to be deployed. This can be performed on demand, just previous to the deployment of an application, or in advance, in order to enable faster deployments.

Finally, the environments template and environment can be retired, redefined or evolved.

Application Deployment

Applications are specified together with the specification of the environment that has to be used for actual deployment. An application is described by the different artifacts that compose it, and the products and configuration attributes required for managing the deployment and configuration. The Application Management Service checks if the application specification is compatible with the environment specification, essentially by checking the compatibility between the product requirements associated to the application and the environment specification. If they are compatible, the Application Management Service coordinates the actual deployment and configuration of artifacts in the environment. Once an application is deployed, a VM or server image is created for scaling the nodes.

Main Interactions

Application Service provides a wide variety of operations to provision and manage the life cycle of applications. The most important ones are listed below.

  • applicationSoftwareCatalogue -- It contains the catalogue with all the applications to be installed.
  • blueprintTemplateCreation -- It creates the definition of the blueprint template in terms of tiers (or specification of hardware and software information).
  • blueprintTemplateDeletion -- It deletes the blueprint templates
  • blueprintTemplateUpdate -- It updates the blueprint templates
  • applicationDeployment -- It deploys the infrastructure (VM, networks..) and the application on top of the VM
  • blueprintTemplateDeployment -- It deploys the blueprint template into the infrastructure

The following picture depicts some interactions between the Application Management, the Orchestration Service and the VM in a typical scenario.

Application Management Interactions
Application Management sequence diagram
  1. The user asks for the application software catalogue
  2. The user creates the blueprint template specifying all the hardware information and the software one
  3. The user deploy the blueprint template
  4. The Application Management service deploy the virtual infrastructure (networks, virtual machines, storages...) by using the Orchestration service
  5. Finally the Application Management install the software in the VM by using the Application Management installed in the virtual machine

Basic Design Principles

Design Principles

The Application Management service has to support the following technical requirements:

  • Decoupling the management of the catalogue (specifications of what can be deployed) and the management of the inventory (instances of what has been already deployed).
  • Asynchronous interface with polling mechanism to obtain information about the deployment status.
  • Decoupling the management of environments from the management of applications, since there could be uses cases where the users of those functionalities could be different ones.
  • Fast elasticity mechanisms, avoiding overhead or repeated work as much as possible during elasticity.

Resolution of Technical Issues

When applied to Application Management service, the general design principles outlined at Cloud Hosting Architecture can be translated into the following design approaches:

  • REST based automated self-provisioning interfaces, both for templates and environment in the deployment of applications.
  • The Application Management service relies on the Orchestration service for service provisioning, and therefore, the multitenancy is offered at the level of IaaS, and not PaaS. Nevertheless, the environments are created per customer on demand.
  • The Application Management service has been designed for elasticity and supports fast elasticity on demand, as requested by the Computing Service.
  • The Application Management service keeps control of all the resources provisioned for each user.

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 FI-WARE. Specifications labeled as "DRAFT" are planned for future Major Releases of FI-WARE but they are provided for the sake of future users.

Open API Specifications

The last stable version of Murano API can be found in the following link.

Nevertheless, you can select other versions (latest, stable-kilo, stable-juno) of the API just selecting them from this web site.

Re-utilised Technologies/Specifications

The Application Management GE is based on RESTful Design Principles. The technologies and specifications used in this GE are:

  • RESTful web services
  • HTTP/1.1 (RFC2616)
  • JSON serialization formats.
  • Python

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 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