What is XLcloud Management Service


XLcloud Management Service (XMS) gives users the ability to manage XLcloud platform. XMS works atop OpenStack infrastructure, introducing Platform-as-a-Service (PaaS) capabilities in OpenStack IaaS. Among main functionalities, XMS provides to stack lifecycle management and software installation automation. Its implementation bases on OpsCode Chef. XLcloud cares to ensure that all instances in the stack share the same set of applications, despite dynamic scaling of stack layers. XLcloud facilitates also advanced network topology management. The power of XLcloud is that, despite giving the easy way to manage PaaS model of cloud computing, it gives the possibility of detailed configuration of the platform, allowing end users to modify the stack lifecycle, and modify low-level settings of the infrastructure. Starting simple, ready to use platform with XLcloud is really easy but if user is willing to make specific modification of the platform, they still can.

One feature that greatly simplifies working with XLcloud platform is the set of predefined blueprints that may be used to start a stack. XLcloud platform provides stack blueprints that may be instantiated with a few clicks, without unnecessary configuration. Users of the platform can also promote they stacks to the stack blueprints, what makes them easy to reuse.

Additional important feature of XMS is advanced identity and access management mechanism. XMS is integrated with OpenAM to provide authentication and fine-grained authorization of users basing on popular open standards. XLcloud accounts are fully isolated from each otherisolates, resulting in production ready multi-tenant environment for multiple purposes (public and private cloud models). Entitlements management allows very fine-grained definition of access policies. Authorized users can grant entitlements on resource-level to accounts, groups, specific users or their access tokens.

XMS comes bundled with multiple client applications, including Web Console, SDK libraries for Java and Python and Command Line Interface. XMS REST API is well documented with examples of requests and responses in case users needed to develop their own client applications or libraries.


The aim of XMS is to provide access to cloud resources - allow to run stacks and deploy applications on top of them. The access is managed through isolated accounts and individual users, with entitlements system that can be precisely configured for each action and resource. The cloud resources may be created and modified on the base on predefined blueprints - that can help and make cloud resource management simple and effective. Therefore, the whole XMS system may be perceived as construction consisting of three pillars: Identity and Access Management, Cloud Resources Management and Cloud Catalogs.

Identity and Access Management Accounts


Account represents an institution, team, or any group of people that want share their work with the cloud resources – stacks and projects. Accounts are charged for the billable resource hours of compute, storage, and network allocated to an account in the context of a stack, and also possibly for the added-value services that are consumed by the users of the account. An account provides privacy and isolation from the rest of the world – users, groups, and stacks are managed within the context of an account. Users belonging to a specific account cannot interact with other accounts in any way. Accounts can also have private cloud catalogs (images, stack blueprints, etc.). Accounts can be created by a platform administrator and are managed and supervised by account administrators, who can grant entitlements to the account members.


The user is the digital representation of a person or an application who uses the services of the system. The authentication service will validate that incoming request are being made by the user who claims to be making the call. Users have a login, and may be assigned tokens to access resources. Users may be directly assigned to a particular account (account members), or be platform administrators. Users can be assigned to groups which determine their privileges. Additionally, entitlements can be assigned directly to individual users

Platform administrators do not belong to any account, and they have most of the privileges. In particular, they can manage accounts. However, they are not allowed to manage stack sessions, nor to create or delete projects. Account members, on the other hand, can create projects and start stacks, provided that they have appropriate entitlements.


Users can be assigned to various account-scoped groups. Groups define entitlements, and users assigned to a certain group gain all those entitlements. This makes groups a convenient way to define roles within the account, or to simply assign the same entitlements to a number of different users.

Access Tokens

Access tokens are used to authenticate the user in XMS. Access tokens can have entitlements associated with them, and a user authenticating with such token gains those entitlements. There are two types of access tokens:

  • token scoped – when you authenticate with such token, you only have entitlements assigned to the token, newly created token-scoped access tokens have no entitlements
  • user scoped – you have both your entitlements (user entitlements and entitlements from groups you belong to) and that of the access token

Access tokens cannot be created using the XMS API.


Entitlements define what a user is allowed to do. Whenever the user tries to perform an operation he is not allowed to, a response with status "403 forbidden" is returned. Entitlements can be assigned to users, access tokens, and groups. Entitlements are associated with the HTTP method(s) and a path. For example:

GET,POST accounts/{account_id}/users


Quotas can restrict any account-scoped resources, limiting the number of resources of a given type in the account. Quotas can limit the following resource types:

  • users
  • stacks
  • stack blueprints
  • layer blueprints


Restrictions represent complete, concise limitation of XMS functionality. They can limit the access to certain resources of all users in a given account, due to accounting reasons (e.g. exceeding account's funds or lack of payment). Restrictions resemble entitlements, except that they deny the access to certain resources, instead of allowing it.

Cloud Resources


Projects provide an organizational structure within an account. Stacks and networks are created and managed within the context of a project. To be able to operate on stacks, you need to be a member of the particular project. Only account members can create and manage projects, provided that they have appropriate entitlements.


Each project has at least one subnet associated with it. Subnets provide isolation and security. The IP range of a subnet is specified as a CIDR, e.g. All projects have one subnet designated as default. When a stack is started, its instances are attached to the default subnet, except if this was changed for individual layers. Subnets that have instanced attached to them cannot be deleted. In particular, the project broker is attached to the subnet that was designated as default at the moment of creating the project.
To operate on subnets you need to be a member of the subnet project.


Leases allows to reserve physical host for your own and make sure no other Stacks gonna be run using this host. Reservation is made for specified timeslot and user is allowed to specified how many resources he wants to reserve. Leases are strictly connected with the project and only project members are allowed to create new leases. Platform administrators are only allowed to modify existing entries including removing them.

OS Keypairs

Keypairs are used to allow the users to connect using SSH with stack instances. Keypairs are associated with users, and a single keypair can be used across multiple projects and stacks within the user's account. Note that only account members can create and use keypairs.

OS Credentials

OS credentials contain all the information that are necessary to authenticate yourself in OpenStack – Keystone user name, Keystone project name, and the Keystone API URL. You only need to know your password.


A stack is a container and a generic partitioning scheme used to group resources and applications, that has specific computing and data processing capabilities. Users can deploy applications on their stacks. Stacks are created within a context of a project. The concept of a stack is the cornerstone concept of the XLcloud project, as it allows for a PaaS-enabling integration technology in the system. The concept of a stack (and stack instances) brings the operational efficiency of the system, in that all the administrative tasks required to manage the lifecycle and the scalability of a stack instance can be reliably and repetitively automated by the system.

Stacks can be created using stack blueprints from cloud catalogs, or they can be custom (freehand) stacks. It is also possible to modify stacks created from blueprints. How the stack was created is indicated by the stack origin. A freehand stack has origin "custom". Stacks created from blueprints have origin "from blueprint", and after their templates are modified, they origin is changed to "customized from blueprint".

Each stack has an AWS template associated with it. Furthermore, stacks generally consist of layers, and it is layers that define concrete resources (like instances). Layers are in fact nested stacks (they are resources of type AWS::CloudFormation::Stack).


Layers are fundamental parts of a stack. Technically, layers are nested stacks, and so they also have AWS templates associated with them. Within a layer, all instances belong to the same subnet, and share the same lifecycle configuration. The lifecycle of a stack is divided into several phases. For each phase a list of recipes – called a "runlist" – is defined. When the stack enters a phase, all recipes from the relevant runlist are executed. Available phases are:

  • setup – executed only when the stack first starts, it cannot be triggered by an event
  • configure
  • deploy
  • undeploy
  • suspend
  • resume
  • shutdown

Except for the "setup" phase, all phases are triggered by corresponding stack events.
Each layer also has a security group defined, that prevents traffic to and from outside the layer subnet.


A session is related to the stack in Heat. Only stacks that are not stopped have a session associated with them. There are a few terminal states a stack can be in:

  • stack can be stopped – does not exist in Heat, and is not taking any resources
  • stack can be running – the stack is active and fully operational
  • stack can be suspended – is not working nor using any resources, and its physical state is saved to be resumed later
  • stack can be failed – "Configure" event or some operation failed in Heat and the stack is unusable


During the stack lifecycle several events take place. They are related to stack status changes, as well as deploying applications. When an event occurs, a message is sent to all instances in the stack (or in one of its layers if it's a "deploy" event), causing them to react according to the runlists defined in their lifecycles. The following events are defined in XMS:

  • CONFIGURE – sent after the stack finishes starting or updating in Heat, and after the RESUME event is processed
  • SUSPEND – sent when the stack is to be suspended, before it is suspended in Heat
  • RESUME – sent after the stack finishes resuming in Heat
  • DEPLOY – sent when an application is deployed on one of the stack layers; it's also sent for each deployed application after the CONFIGURE event is processed
  • UNDEPLOY – sent when an application is undeployed
  • SHUTDOWN – sent when the stack is to be stopped, before it is stopped in Heat

Events have outputs which present results of the event for each instance.

Application Deployments

Application Deployment represents the act of deploying application on the layer. Deployment is executed by invoking the runlist of recipes for the "deploy" phase of the layer lifecycle. Depending on the configuration of the lifecycle, an application deployment may need to specify values of runlist cookbook attributes.

Cloud catalogs

Catalogs are sets of resource templates that may be reused to creating new resources allowing to the job quickly and effectively. All catalog objects may be made public - allowing all users in the platform to use them without restrictions, or private - allowing access only to the selected users in the account.

Stack Blueprints

Stack blueprints allows users to create stacks easily. Users can create stacks by specifying a blueprint. Such blueprint defines the stack template, its layers, default values of its parameters, and other elements necessary to get a stack up and running. Stack blueprints are grouped into catalogs.

Layer Blueprints

Layer blueprints allows users to create layers easily. Users can add layers to their stacks by specifying a blueprint. Such blueprint defines the layer template and other necessary elements. No default parameter values are defined by layer blueprints. All values need to be specified by the user after creating the layer. Layer blueprints are grouped into catalogs.


Cloud images are virtual machine images used to create individual instances of a stack. When creating a stack you specify what image(s) will be used for its instances.


XLcloud uses Chef as the tool to install software on stacks, and configure them to work. Repositories are containers of Chef cookbooks. By using a repository, all cookbooks needed to configure a stack may be added with by cloning just a single git repository.

Repositories are identified by their URI and, optionally, a reference. This can be anything that git recognizes as a reference (like branch name, tag name, SHA, or SHA unique prefix).

Repository cookbooks must contain the "metadata.json" file. It can be located either in the top-level directory or in its immediate subdirectories.


Cookbooks are the fundamental units of configuration. Each cookbook defines a scenario, such as everything needed to install and configure MySQL, and then it contains all of the components that are required to support that scenario.
Cookbooks can define dependencies and attributes using the "metadata.json" file.


Recipes represent Chef recipes. A recipe is a basic element that may be used to configure the lifecycle management of layers in a stack.  It represents a basic step of configuration of the layer environment. It is a Ruby script that may be executed on instances of a layer to configure the environment. Runlists of recipes are executed on lifecycle events. Recipes have to be part of the cookbook and can be create only by registering a repository. Recipes are identified in the platform by their name.
Recipes may be parameterized. Parameters are common to the whole cookbook and their values may be defined during application deployment.

This wiki is licensed under a Creative Commons 2.0 license
XWiki Enterprise 5.4.6 - Documentation - Legal Notice

Site maintained by