Contrail Scenario


http://contrail.projects.ow2.org/xwiki/bin/download/XWiki/amiraow2/contrailarchi1.1.png

This figure shows the main components of Contrail. Some of these components are implemented by various distributed services on different layers of the software stack, offering a common interface to other services. The major interactions are identified in this figure as follows:

1.the user authenticates with the authentication service provided by the federation services which contact the online CA component.
2. the user interacts with the federation portal to negotiate SLAs and manage applications through the RESTful API;
3. the federation contacts the authorization service before negotiating the application with the user.
4. the authorization service gathers the information about the user from the authentication service;
5. the federation layer negotiates SLAs with the provider on behalf of some user through the SOAP client library;
6. in order to provide guarantees concerning resource availability during SLA negotiation, the SLA manager interacts with the VEP to reserve the resource if asked by the user. For instance to materially instantiate the application into the cloud provider and optionally make advanced resource reservations based on the negotiated SLA.
7. the federation layer interacts with the provider resource layer to manage applications through the Provisioning Manager API;
8. the provisioning manager interacts with the SLA manager at the provider layer to retrieve information concerning the SLAs to manage the elasticity of the application;
9. the provisioning manager interacts with the provider resource layer to manage applica- tions through the VEP RESTful API.
10. before the application deployment and during the execution, the VEP layer obtains au- thorization decisions by the interaction with the Policy Decision Point’s client library written in Java.
11 before the application deployment the VEP works as trusted third party for the VIN agents to obtain certificates from the authorisation service via the OAuth2 client;
12. the management and monitoring agent registers a VM with the monitoring service and publishes the monitoring data according to the API;
13. after SLA negotiation, the SLA manager registers with the monitoring service to receive all monitoring data generated by the resources consumed on behalf of this SLA;

14. the SLA enforcement service registers with the monitoring service and generates the violation or warning messages from the monitoring data produced by the lower layers using the SLA Enforcement API
15. the federation layer registers with the monitoring layer using the Monitoring API to receive monitoring and accounting data published about the user and applications by the lower layers;
16. the accounting service at the federation layer registers with the monitoring using the Monitoring API;
17. the federation layer registers with the accounting service using the Accounting API to receive accounting data published about the user and applications by the lower layers;
18. the user pulls accounting and monitoring data of his applications from the federation using the RESTful federation API. Other notification models are planned for future releases;
19. the user reads and stores data as well as virtual machine images in their GAFS volumes. This operation is optional as indicated by the dotted line;
20. virtual machines mount user volumes;
21. the federation layer manages virtual machine images on GAFS;
22. GAFS services request PDP decisions to allow access to virtual machine images and user data.