CompatibleOne FAQ

Which interfaces for CompatibleOne?
Can CompatibleOne provision more than one cloud service?
What about the network?
Who should use CompatibleOne and Why ?
How does the CompatibleOne ecosystem work?
Glossary, Acronyms and Abbreviations

1) CompatibleOne: How does it work?

1st Step: Handling the user's requirements 
The user's requirements are expressed in a service manifest document which describes in detail the services to be delivered, the technical and economical criteria and the constraints that are to be taken into consideration. The structure of the contents of this manifest corresponds to the model described by CORDS (CompatibleOne Resource Description System).

2nd Step: Validation and construction of the provisioning plan
The manifest is received by the SLAP MASTER allocation engine which initiates the transactional event management, destined to be used by the accountancy and billing system. The manifest is then transfered to the CORDS Parser where the XML dexcription will be transformed into a fully qualified and validated provisioning plan. The CORDS Parser first checks the syntactical validity of the manifest document and then ensures the existance of the appropriate resources for the understanding and expression of the needs as they are expressed.

3rd Step: Execution of the provisioning plan
Once the plan has been validated, it will be transfered to the CORDS Broker which will be responsible for the actual provisioning operation requiring the creation of a control graph for the management of the different components involved in and resulting from the provisioning process. During this operation the CORDS Broker will make use of the different CompatibleOne brokering services required to satisfy the constraints described in the initial manifest, using for example a request optimisation service.

4th Step : Delivery of the Cloud Services
The CORDS Broker establishes and engages service contracts with each of the individual Cloud Providers required for the provision of the different components in a contractual manner.
The capacity of these Providers to make available their resources and services is discovered by the CORDS Procci through the CORDS Publisher and the announcements of service performed there by  each Provider. Communication with the different Providers is performed through client/server interfaces described using the standard OCCI and implemented on the CompatibleOne side within the CORDS Procci and on the Provider side within a Provider specific Procci component. In this way we find a proxy per Provider including the OpenNebula Procci, the OpenStack Procci, an Amazon Procci or a Windows Azure Procci for example. In this way the implementation of a Provider specific proxy is all that is required to be performed  in order to make ressources available for use within the CompatibleOne provisioning system. A template server implementing the different aspects of the OCCI / REST server available on demand to facilitate this.

The Knowledge Base
The elements stored in the Knowledge Base are the Manifests, the Plans, the Contracts and the Services. A unique and universal identifier is attributed to each element in the Knowledge Base and may be used to reference the element for use in subsequent solutions. This can be in the definition of topologies specific to certain activities such as clouds for High Performance Computing or as an Internet Service Provider or SaaS Editor.

The Publisher
ACCORDS (Advanced Capabilities for CORDS) is actually the Provisioning System for CompatibleOne. 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 (Open Cloud Computing Interface) over HTTP (Hyper Text Transfer Protocol). This collection of protocols and specifications constitutes the cloud middleware or cloudware offered by ACCORDS.

2) Which interfaces for CompatibleOne?

First it seems  all CompatibleOne components use REST to communicate. It seems that each “cloud provider” is accessed through an OCCI proxy which is then perhaps translated to the native API (e.g. OpenStack).  However the interfaces between the different CompatibleOne components (e.g. publisher, parser or broker) are so far not published on CompatibleOne's  web site. Where could we have access to these? 
This understanding of the architecture is exact, the different proxy components, or proccis, in CompatibleOne jargon offer a standard OCCI interface to the generic procci for the 'negociation' of contract instances over a REST interface. The interface has not been published as such, simply because it is a standard OCCI REST interface and the usual OCCI capacity discovery mechanisms are available for clients to be able to consult the different server components with respect to their interface categories and their associated actions. Each of the interface  categories will of course be fully documented  as they reach maturity during the project. 

3) Can CompatibleOne provision more than one cloud service?

Is the aim of compatible one is “to be able to deploy an application across more than one cloud”, or to only deploy an application in one of the possible clouds? Either for the initial deployment or later for life cycle management (e.g. scale up). From the resource description schema, it does not seem that this is currently envisaged. But is this in the CompatibleOne roadmap?
The architecture was devised to be as flexible as possible for the description of complex cloud systems. It is intended for a wide range of uses from the simple private corporate infrastructure usage to the fully blown public infrastructure cloud broker. The differences really lie in the way the platform is configured to behave by the actual operator.  A Manifest  however may declare that a node be contractually instanced through a specific cloud provider for technical reasons, or it may be left to the broker to decide taking into consideration financial, energetic, geographic or operator contractual preferences. A complete service manifest may describe nodes provisioned by different cloud providers and being "sewn" together by the configuration section of the manifest. 

4) What about the network?

From the point of view of the network, this schema defines an L2 network.  OCCI model is used here. Reading the documentation, it is difficult to know if CompatibleOne will use the NetworkLink to create links (routes/firewalls) between created networks. However for now, it seems that what is supported is that a single “network” is created and the VMs/storage are deployed within that network. So is it possible to know more of CompatibleOne road map on  this item?
As far as networking goes, in the current state of the CompatibleOne platform, the aim is to provide an automatic provisioning system and would indeed appear to target a single network but in fact, in order that the provisioning may scan multiple and heterogeneous cloud provider platforms, the idea of a single network is very much ruled out since the different VM's would be within the local network space of each provisioner. In such complex cases the CompatibleOne platform aims at provision of the necessary network components, be they simple public IP addresses or more complex VPN and tunnelling configurations. Devices of this kind, including routers and firewalls are intended to be described in the same terms as othe nodes with the concerned Manifest. Symmetry is the aim here, as far as possible.

5) Who should use CompatibleOne and Why ?

Open cloud has a strong potential for the catalysis of new ideas and initiatives.  CompatibleOne is as such a good example. By establishing the necessary foundations for the operators, developers and architects of cloud computing, CompatibleOne facilitates the creation of new services and even new professions.
Cloud Operators would be able to use CompatibleOne cloudware to maximize returns in the exploitation of their data centers in terms of economical, technical and geographical criteria. The CORDS model was designed to be usage driven and these operators could eventually define their infrastructures in accordance with their target market be they provision of internet services, hosting, on demand HPC and so on and so forth.
A cloud entrepreneur would be able to offer, thanks to CompatibleOne, and in complete independance  with respect to the choice of actual operator, services to their clients with a high added value. It would become possible, for example, to imagine the provision of a courtier service based on diverse criteria, their professional orientation (automobile, aeronautics, defense, agriculture, …) or their economical constraints (the best cloud services or the best price offered to local government for example).
Finally, for a software developer and vendor, CompatibleOne cloudware provides the ideal tools  for the construction of new and inovative offers of highly competitive services compared to those already available. Detailled billing of service would be possible allowing examination of actual and real service consummation with an aim to optimisation of the resources required. In addition these services would be offered in form of SaaS.

6) How does the CompatibleOne ecosystem work?

CompatibleOne is an Open Source project, open to all, the results of which can be freely reused, modified and distributed. The availability of the entire code base and its documentation under open source license makes possible not only the adoption of this Cloudware but also aims at encouraging participation from new contributors in order to enrich and enhance the existing code base.  CompatibleOne is part of the open source cloudware initiative of OW2 (OSCi) aiming to establish and encourage synergy between open source projects and players in cloud computing area.
CompatibleOne was made possible thanks to the support of French competitiveness clusters Systematic and Solutions de Communications Sécurisées, FUI (Fonds Unique Interministériel), Paris Region (Ile de France), Conseil Général des Yvelines and the Paris Town Hall. To date, the participants and contributors are ActiveEon, Bull, CityPassenger, Enovance, Eureva, INRIA, Institut Télécom, Mandriva, Nexedi, Nuxeo, OW2, Prologue, Xwiki. CompatibleOne is open toany new contributor.
It is also the objective of CompatibleOne to provide models, specifications and components for re-use in subsequent projects such as   EasiClouds, CloudForce, CloudPort, Magellan, and there by facilitating the development of open source industrial solutions and open cloud computing services in France and Europe.
CompatibleOne will make intensive use of existing open standards, such as OCCI and intends to contribute also to their specifications. In addition links are established with projects sharing similar goals such as OpenNebula and Contrail.

7) Glossary, Acronyms and Abbreviations