Contribute to CompatibleOne
CompatibleOne is a free, open source project. Please feel free to contact us if you have any questions about the project or any suggestions on how to improve CompatibleOne. The CompatibleOne developer community is open to anyone that wants to contribute!
General Information
CompatibleOne is composed of 2 key components for the description, provisioning and integration of various cloud resources and services provisioned by heterogeneous Cloud Service Providers:
- an open model named CORDS (CompatibleOne Resource Description System) licensed under a Creative Commons Attribution 3.0 Unported License
- This object oriented model enables to describe in any type of cloud services. This model is based on OCCI
- CORDS Reference Manual V2.15
- Cords.xsd is used by all documents to import collections of category instances eg infrastructure, package, system descriptions
- Cordstypes.xsd provides the definitions of all complex types used in the cords.xsd and manifest.xsd
- Manifest.xsd is the schema to be used for manifest documents
- Slam.xsd is the schema to be used for SLA Management
- Cordscript Reference Manual V1.2 describes the Cordscript language which may be used to describe additional behavior and dynamicity to a manifest
- This object oriented model enables to describe in any type of cloud services. This model is based on OCCI
- a free, open source software named ACCORDS (Advanced Capabilities for CORDS) licensed under Apache License Version 2.0
- ACCORDS is actually the Provisioning System for CompatibleOne: it provides all the necessary capabilities of a Cloud Services Broker (intermediation, aggreagation and arbitrage). All communication within ACCORDS is performed in conjunction with the Publication Service offered by the Publisher, working in tight coordination with the Security Service COSS (CompatibleOne Security Service) and using OCCI over HTTP. This collection of protocols and specifications constitutes the cloud middleware offered by ACCORDS.
This page provides you with useful information about:
How to get CompatibleOne Package
How to get source code and install CompatibleOne
How to use ACCORDS
What are ACCORDS Services
Configuration for Open Stack Provisioning
CORDS Manifest
How ACCORDS manages a PaaS
COAPS: CompatibleOne Application and Platform Service
How to get CompatibleOne Package
If source code is not needed, Accords-platform package for CentOS / Fedora / RedHat can be found on build.opensuse.org
NEW CompatibleOne DEBIAN & UBUNTU package is available on compatibleone.org/debian/
Get it, install it then start Accords
How to get source code and install CompatibleOne
Get Source Code
Accords source code is avalaible on OW2 gitorious
git clone http://git.gitorious.ow2.org/ow2-compatibleone/accords-platform.git
Install CompatibleOne
Once accords-platform is cloned, in order to build and install, run
./autogen.sh
./configure [options]
make
make install
How to use ACCORDS
ACCORDS – The Basics
OCCI was selected as the basis for the implementation of the CORDS model and also for the rendering of the model using REST over HTTP. Each operational service provider component of the platform is a standalone OCCI, REST, HTTP server responsible for the management of a specific collection of categories. Each category corresponds to an element of CORDS.
Here is an example of Trace of OCCI Requests generated by ACCORDS during demonstration at OCCI Cloud Plug Fest in Dusseldorf on the 29th February 2012.
Security
The security of the platform is based on the principles of Transport Layer Security and is compliant with the most recent specifications published by the IETF in this respect. The exchange of Certificates between components of the platform is intended and encouraged but not mandatory. The authorization and authentication of all communicating endpoints is required to be performed prior to any other activity when platform security has been activated.
Which Language for ACCORDS
Operational service provider components provided in Accords-platform are implemented in C (except EZVM implemented in Python).
Note: An ACCORDS component can be implemented in any language if:
- this component manages standard OCCI/REST messages
- this component is aware of ACCORDS architecture and services (Coss, Resolver, Publisher, Parser, Broker,...)
ACCORDS Scripts
A collection of OCCI server components are provided along with command line tools allowing the basic operations to be performed. To facilitate the use of these tools a collection of scripts are generated during installation providing the precise parameters required to be specified for the correct operation of the platform.
| co-start | this script launches the complete collection of platform components in the required order |
| co-stop | this script will stop the collection of platform components in the correct order |
| co-status | this script displays the current presence of the collection of platform components |
| co-parser mymanifest | This script may be used to parse a manifest to produce a provisioning plan (mymanifest.xml) |
| co-broker mymanifest | This script may be used to process a provisioning plan to provision the resources of a service. |
| co-command start service/{uuid} | This command will start a service instance if it is currently in the stopped state otherwise it will be silently ignored. Starting a service instance involves deploying the provisioned resources and when required will initiate priced transactions through the financial channels. |
| co-command stop service/{uuid} | This command will stop a running service instance if it is currently in the active or started state otherwise it will be silently ignored. Stoping a service instance involves release of the provisioned resources and when required will terminate priced transactions through the financial channels. |
| co-command save service/{uuid} | This command will save the image of a running service instance if it is currently in the active or started state otherwise it will be silently ignored. The image saved will become the image of the service if it is stopped and then restarted. This function allows a snapshot to be taken and allows a failover restart point to be established. This operation may be priced in which case transactions will ensue. |
| co-command delete service/{uuid} | This command will delete a service instance and its control graph from the ACCORDS platform. If it is currently active and running the service will be stopped and all provisioned resources will be released. The service and contract descriptions referenced through its service instance identifier will be deleted and the instance identifier will become invalid |
ACCORDS Services
This is the list of available ACCORDS platform services resulting of co-status:
# co-status
-
Accords Platform Components
-
tcp 0 0 *:8086 *:* LISTEN 18860/publisher
tcp 0 0 *:xprint-server *:* LISTEN 18865/fileserver
tcp 0 0 *:8087 *:* LISTEN 18870/coss
tcp 0 0 *:radan-http *:* LISTEN 18876/comons
tcp 0 0 *:8090 *:* LISTEN 18887/conets
tcp 0 0 *:8091 *:* LISTEN 18881/coobas
tcp 0 0 *:8089 *:* LISTEN 18894/cops
tcp 0 0 *:8103 *:* LISTEN 18899/coees
tcp 0 0 *:8092 *:* LISTEN 18916/parser
tcp 0 0 *:8093 *:* LISTEN 18921/broker
tcp 0 0 *:8094 *:* LISTEN 18926/procci
tcp 0 0 *:8095 *:* LISTEN 18936/osprocci
tcp 0 0 *:8104 *:* LISTEN 18931/cosched
tcp 0 0 *:8101 *:* LISTEN 18904/ezvm
tcp 0 0 *:8102 *:* LISTEN 18911/coips
tcp 0 0 *:8286 *:* LISTEN 18951/cosacs
This diagram shows the service oriented architecture of ACCORDS platform 
Click to enlarge
Service Publication
The publication service constitutes the central hub around which the ACCORDS platform is built and promotes interoperability through the loosely coupled and highly extensible interfaces presented to the rest of the platform.
- Publisher: The publisher is responsible for the management of service publications performed by the components comprising the platform. Each of the different service provider components comprising the platform will publish its collection of categories for use by other components. The publisher is provided as a standalone OCCI REST server executable program and must have been started before any of the other components may be used. The command is launched by the “run-publisher” script launched from the “co-start” script.
$ publisher --config accords.xml PUBLISHER/1.0
- Resolver: The resolver library allows the publisher to be consulted for discovery of the collection of service providers for a particular category of service. This is performed by the service consumer processes of the platform during their normal operation. Service categories may be filtered by category name, operator type, geographical location or by price and allows publication of multiple offers for any particular category type. The resolver is available as a shared object type C library package and a standalone command line tool allowing inspection of publications for a particular named category.
$ testresolver categoryname1 categoryname2
Resource Provisioning
The term provisioning, when used in respect to the ACCORDS platform, refers to the composite act of selecting a provisioning platform type and then determining the operator platform to be used. The resources are then provisioned using the appropriate provider specific interfaces as encapsulated by the appropriate ACCORDS platform connector.
- Parser: The parser is provided as a standalone OCCI REST server executable program and must have been started before any manifest processing may be performed. The command is launched by the “run-parser” script launched from the “co-start” script.
$ parser --config accords.xml PARSER/1.0
$ testcp --publisher http://127.0.0.1:8086 manifest.xml
- Broker: The broker is provided as a standalone OCCI REST server executable program and must have been started before any provisioning plan processing may be performed. The command is launched by the “run-broker” script launched from the “co-start” script.
$ broker --config accords.xml BROKER/1.0
- A standalone command line tool, “testcb”, may be used to submit a provisioning plan XML file for processing by the broker for the production of a service instance control graph. Upon completion of the service instance the corresponding resources will be provisioned and engaged or started. The broker will produce a service description file in the “service” directory containing the details of the contracts negotiated during this operation and providing the access details and network addresses required for use of the provisioned resources.
$ testcb --publisher http://127.0.0.1:8086 plan_manifest.xml
- PROCCI: This component of the ACCORDS platform is responsible for the management of generic provisioning contracts as requested by the service broker during the creation of the service instance control graph. Provider specific contracts will be negotiated here using the provider specific procci components as required by the description of the node to be provisioned. This standalone OCCI REST server executable program and must have been started before any provisioning plan processing may be performed for the provisioning of resources. The command is launched by the “run-procci” script launched from the “co-start” script.
$ procci --config accords.xml PROCCI/1.0
- COPS: The CompatibleOne Placement Services module is a standalone OCCI REST server executable program and must have been started before any provisioning plan smart placement processing may be performed for the provisioning of resources. The command is launched by the “run-cops” script launched from the “co-start” script. This component is of particular importance as a target or consumer of monitoring information in the form of provisioning alerts which will be used in the elaboration of the scoring information that will be used to influence the selection of particular provider platforms during subsequent placement operations.
$ coes --config accords.xml COPS/1.0
- COEES: The CompatibleOne Energy Efficiency Service component is a standalone OCCI REST server executable program and must have been started before any provisioning plan energy efficiency processing may be performed for the provisioning of resources. The command is launched by the “run-coees” script launched from the “co-start” script.
$ coees --config accords.xml COEES/1.0
- CONETS: The CompatibleOne Network Services component is a standalone OCCI REST server executable program and must have been started before any provisioning of application images may be performed through the broker. The command is launched by the “run-conets” script launched from the “co-start” script.
$ conets --config accords.xml CONETS/1.0
- EZVM: This standalone OCCI REST server executable program enables the instantiations of VM on various cloud service providers while providing a complete abstraction of the portability problems for the consumer. It also enables to move from one cloud to another by running VM images on various providers. EZVM must have been started before any manifest parser image production processing may be performed for the provisioning of application images for computational resources. The command is launched by the “run-ezvm” script launched from the “co-start” script.
$ ezvm --config accords.xml EZVM/1.0
- COIPS: The CompatibleOne Image Production Services module is a standalone OCCI REST server executable program and must have been started before any manifest parser image production processing may be performed for the provisioning of application images for computational resources. The command is launched by the “run-coips” script launched from the “co-start” script.
$ coips --config accords.xml COIPS/1.0
- COSACS: The CompatibleOne Software Appliance Configuration Services module is a standalone OCCI REST server executable program that will have been embedded in the application image produced by the preceding Application Image Production tool. The component will be used through the provisioning procci components for the personalization of the application image during resource deployment startup. The module also provides the monitoring control channels for trhe activation of monitoring agents and their data collection probes. The command is launched, within the provisioned virtual machine image by the “run-cosacs” script.
$ cosacs --config cosacs.xml COSACS/1.0
Security Services and Extensions
The principles, on which the security of the platform depends, require the use of Transport Layer Security (TLS 1.0) to be announced and accepted by all server and client endpoints. The exchange of Certificates between communicating endpoints is strongly encourage. Authentication of processes and users must be performed through an identity management system and will result in authorization being accorded for access to the platform and its components.
- COSS: The CompatibleOne Security Services component is a standalone OCCI REST server executable program and must have been started after the publisher and before all other components of the platform. The command is launched by the “run-coss” script launched from the “co-start” script.
$ coss --config accords.xml COSS/1.0
- Identity Management: Currently the COSS component itself plays the role of identity management but this role will be assumed by extensions or connectors to third party identity management packages such as LDAP, SQL, PING and other platform specific single sign on solutions.
- The CompatibleOne Security Services component has been identified as being a consumer of monitoring information and as such may be used as the target of monitoring instructions as defined using Cordscript expressions in a provisioning manifest.
Monitoring Services and Extensions
- COMONS: The CompatibleOne Monitoring Services component is a standalone OCCI REST server executable program and must have been started after the security services and before all other components of the platform. The command is launched by the “run-comons” script launched from the “co-start” script.
$ comons --config accords.xml COMONS/1.0
- Agents: The monitoring data collection end point is provided by the monitoring agent. This component resides on the provisioned infrastructure platform and is activated through the monitoring control channel from the COMONS component.
- Probes: The individual types of monitoring data are each to be collected by particular monitoring probes under the control of their monitoring agent interface. Data collected in this way will be returned to the monitoring data consumer through the agent interface.
- Consumers: Monitoring data consumers are present in certain components of the ACCORDS platform and provide processing of the data to ensure the correct operation of the platform processes and their deployed products.
This diagram describe the monitoring categories of ACCORDS platform 
Click to enlarge
Financial Services and Extensions
The ACCORDS platform makes provision for the generation of financial transactions whenever a request for the creation of a category occurs for which price information is detected to have been defined. In addition, specific provisioning operations may also define prices for the deployment of their resources. This allows a platform operator fine control over definition of their commercial pricing or internal costing policy and this in terms of individual categories of resources and their different acts of provisioning. These transactions are generated with respect to a particular account and may be retrieved from their category manager for the processing required by operator specific accountancy, invoicing and decisional software.
- COOBAS: The CompatibleOne Ordering, Billing and Accountancy Services component is a standalone OCCI REST server executable program and must have been started after the monitoring services and before all other components of the platform. The command is launched by the “run-coobas” script launched from the “co-start” script. This component is responsible for the management of the platform price list comprising the prices of the different categories and provisioning operations. This information is intended to be configured using external user interfaced tools provided by third party software vendors but can also be configured by hand by editing the corresponding category configuration file, “cords_price.xml”, prior to launching the COOBAS module.
$ coobas --config accords.xml COOBAS/1.0
- Billing Suite: The COOBAS component makes transactional information on an account basis for use by invoicing software, provided by third parties, as required by the configuration of the operator platform. This is possible due to the standard OCCI interface exposed by this module. As a demonstration of this the COOBAS component offers an invoice category management that produces an HTML technical rendering of an invoice and its transaction in response to REST requests POST and PUT received by the module and providing valid account credentials.
- Accountancy Suite: Accountancy and other financial software may also be interfaced through the OCCI interface for the consumption and processing of financial transactional information managed by the platform.
Example of Configuration for Open Stack Provisioning
The Open Stack provisioning platform uses the platform specific terms FLAVORS, IMAGES and SERVERS for the description of resources and resource pools.
- OSPROCCI: This component of the ACCORDS platform is responsible for the management and provisioning of resources on an Open Stack provisioning platform and publishes the “openstack” provisioning category. Provisioning through this interface may be selected using the “provider” attribute of a node description set to “openstack”. The configuration file “os_config.xml” provides OpenStack subscription account details that must be prepared before the OSPROCCI component is started and has the following format:
<os_configs>
<os_config
id="e1f892e3-0001-4326-8866-9354b95d3b17"
name="{userid}"
user="{userid}"
password="{password}"
namespace="{domain}"
description="Configuration of CompatibleOne Hands On Meeting Account"
agent=’OpenStackClient/1.0a.0.01’
host=’http:94.143.114.137:5000/v2.0/’
version="v1.1"
authenticate=""
base=""
tls="0"
current="0" />
</os_configs>
- TESTOS: This command line tool allows inspection of the Open Stack platform resources that are available or have been provisioned using the following command line syntax:
testos –host {host] –user {username] –password {password} {command}
- The term {command} may be one of the following:
- LIST FLAVORS: Returns the list of flavors currently defined for the particular OpenStack platform.
- LIST IMAGES: Returns the list of images current available on the OpenStack platform
- LIST SERVERS:Returns the server instances provisioned on the OpenStack platform.
- RETRIEVE FLAVOR {flavorId}: Returns the details associated with the specified flavor identifier.
- RETRIEVE IMAGE {imageId}: Returns the details associated with the specified image identifier.
- RETRIEVE SERVER {ServerId}: Returns the precise details and Meta data collection associated with the specified server instance identifier.
- REMOVE SERVER {ServerId}: Deletes the server instance and releases all provisioned resources.
CORDS Manifest
This category corresponds to the outermost element of the CORDS manifest document structure. It is used to define a particular cloud provisioning configuration comprising nodes, configuration actions, accounting and security information. The manifest is the basic work unit of the ACCORDS platform from which a provisioning plan is produced by the operation of the ACCORDS Parser. The resulting plan provides the description of the system for the brokering and provisioning operations of the ACCORDS Broker.
Manifests Examples
The following examples are showing how a manifest must be described in order to provision, deploy and install a complete Xwiki application and its MySQL DBMS. Both can be located on the same cloud (as shown in example 1 with OpenStack) or they can be distributed on different clouds (as shown in example 2 with Xwiki on OpenStack and MySQL on OpenNebula)
Example 1: XWiki using a Private MySQL on OpenStack
<manifest name="xwikios" xmlns="http://www.compatibleone.fr/schemes/manifest.xsd">
<description>The XWiki application using a Private MYSQL on OpenStack</description>
<node name="osdatabase" type="mysqlos"/>
<node name="xwiki" type="simple" access="public" scope="normal" provider="openstack" >
<infrastructure name="xwiki">
<compute name="xwiki" architecture="x86_64" cores="1" memory="1G" speed="1G"/>
<storage name="xwiki" size="10G"/>
<network name="xwiki" label="ethernet" vlan="100M">
<port name="http-alt"
description="xwiki application server access"
protocol="tcp"
number="8080"/>
</network>
</infrastructure>
<image name="xwiki">
<system name="POC1V2.4h"/>
</image>
</node>
<configuration name="xwikios">
<action name="xwikios" expression="xwiki.configure(osdatabase.mysqlos.hostname);"/>
<action name="xwikiose" expression="xwiki.system('export database_mysql_hostname=$osdatabase_mysqlos_hostname');"/>
<action name="xwikigo" expression="xwiki.fork('bash /root/xwiki.sh');"/>
</configuration>
<interface name="xwikios"/>
<account name="test"/>
<security name="xwikios"/>
</manifest>
<manifest xmlns="http://www.compatibleone.fr/schemes/manifest.xsd" name="mysqlos">
<description>The Private MySQL service for OpenStack</description>
<node name="mysqlos" type="simple" access="private" scope="normal" provider="openstack">
<infrastructure name="mysqlos">
<compute name="mysqlos" architecture="x86_64" cores="1" memory="1G" speed="1G"/>
<storage name="mysqlos" size="10G"/>
<network name="mysqlos" label="ethernet" vlan="100M"/>
</infrastructure>
<image name="mysqlos">
<system name="debian_with_cosacs"/>
<package name="mysql1" installation="wget http://gitorious.ow2.org/ow2-compatibleone/cosacs-repository/blobs/raw/master/debian_squeeze/mysql/install.sh; bash install.sh" configuration="#"/>
</image>
</node>
<configuration name="mysqlos"/>
<interface name="mysqlos"/>
<account name="test"/>
<security name="mysqlos"/>
</manifest>
Example 2: XWiki using a Public MySQL on OpenNebula
<manifest xmlns="http://www.compatibleone.fr/schemes/manifest.xsd" name="xwikion">
<description>
The XWiki application using a Public MYSQL on OpenNebula
</description>
<node name="ondatabase" type="mysqlon"/>
<node name="xwiki" type="simple" access="public" scope="normal" provider="openstack">
<infrastructure name="xwiki">
<compute name="xwiki" architecture="x86_64" cores="1" memory="1G" speed="1G"/>
<storage name="xwiki" size="10G"/>
<network name="xwiki" label="ethernet" vlan="100M"/>
</infrastructure>
<image name="xwiki">
<system name="POC1V2.4h"/>
</image>
</node>
<configuration name="xwikion">
<action name="xwikion" expression="xwiki.configure(ondatabase.mysqlon.hostname);"/>
<action name="xwikione" expression="xwiki.system('export database_mysql_hostname=$ondatabase_mysqlon_hostname');"/>
<action name="xwikigo" expression="xwiki.fork('bash /root/xwiki.sh');"/>
</configuration>
<interface name="xwikion"/>
<account name="test"/>
<security name="xwikion"/>
</manifest>
<manifest xmlns="http://www.compatibleone.fr/schemes/manifest.xsd" name="mysqlon">
<description>The Open Nebula MySQL service</description>
<node name="mysqlon" type="simple" access="public" scope="normal" provider="opennebula">
<infrastructure name="mysqlon">
<compute name="mysqlon" architecture="x86_64" cores="1" memory="1G" speed="1G"/>
<storage name="mysqlon" size="10G"/>
<network name="PUB_Compatible" label="ethernet" vlan="100M"/>
</infrastructure>
<image name="mysqlon">
<system name="ubuntu_with_cosacs"/>
<package name="mysqlon1" installation="wget http://gitorious.ow2.org/ow2-compatibleone/cosacs-repository/blobs/raw/master/debian_squeeze/mysql/install.sh; bash install.sh" configuration="#"/>
</image>
</node>
<configuration name="mysqlon"/>
<interface name="mysqlon"/>
<account name="test"/>
<security name="mysqlon"/>
</manifest>
How ACCORDS manages a PaaS
To set up a PaaS with ACCORDS, 3 types of manifests are necessary which will be sequentially parsed and brokered on ACCORDS:
1. PaaS Manifest
This manifest describes how to deploy and instantiate the targeted PaaS.
To add a new PaaS, the execution sequence is the following:
- Startup of ACCORDS platform,
- Parsing of PaaS Manifest (see paasmanifest.xsd et paastypes.xsd) to produce convenient provisioning plan,
- Brokering of PaaS provisioning plan to launch the PaaS.
Once the PaaS is deployed, its categories are published by ACCORDS Procci.
of ACCORDS PaaS process.
Click to enlarge
2. Container Manifest
PaaS sitting on top of any IaaS, this manifest describes how to provision PaaS resources from the IaaS. The communications between PaaS and IaaS are ensured by ACCORDS broker.
To add a new PaaS resource, the execution sequence is the following:
- Parsing of the Container Manifest to produce provisioning plan,
- Brokering of the Container provisioning plan to provision PaaS resources.
This figure describes the 2nd step
of ACCORDS PaaS process.
Click to enlarge
3. Application Manifest
This manifest (example) describes the application to deploy. This manifest defines also the environment (container) in which the application must be deployed among those available or, where appropriate, to describe a new one.
To deploy an application on a running PaaS, the execution sequence is the following:
- Asking the PaaS REST API for provisioning and starting the appropriate environment,
- Parsing of the Application Manifest to produce provisioning plan,
- Brokering of the Application provisioning plan to deploy application on the PaaS,
- Asking the PaaS REST API to deploy and manage application on the PaaS.
The PaaS REST API is generic and is the same for all the deployed PaaS. It exposes a set of operations to manage environments and applications deployed on these PaaS.
of ACCORDS PaaS process.
Click to enlarge
COAPS: CompatibleOne Application and Platform Service
To allow Cloud cooperation and Federation, each company's Cloud must be able to seamlessly interact with different and heterogenous PaaS solutions (e.g. Cloud Foundry, Openshift, etc.). CompatibleOne offers a generic API that enables human and/or software agents to provision and manage their applications to a PaaS. This API provides an abstraction layer and a middleware for existing PaaS solutions to provision applications in a generic fashion (see Figure below).
Click to enlarge
COAPS exposes a generic interface which has been implemented according to the different actions exposed by a PaaS Solution. In this way, to interact with a new PaaS, we only need to develop its specific API implementation. For instance, a CloudFoundry-PaaS API implementation will act as a middleware between the user and a CloudFoundry PaaS.
COAPS provides environments and applications management operations. The table below provides a summary of the different Application and environment management operations and their associated REST method and resource identifiers. More informations can be found in the COAPS specifications (1.5.3) documentation.
Click to enlarge
CompatibleOne has two implementations of COAPS for the time being: a Cloud Foundry implementation (CF-PaaS API) and an Openshift implementation (OS-PaaS API). Both implementations are written in Java and provided as RESTful (using the Jersey JAX-RS (JSR 311) implementation) Web applications. A Web client also exists to test the different COAPS implementations. These implementations are available as open source under Apache 2.0 licence and the latest stable version of the project can be retrieved here.
Cloud Foundry.com and on OpenShift.com
using COAPS through the Web client
