Difference between revisions of "Fedcloud-tf:WorkGroups:Brokering"
Jump to navigation
Jump to search
m |
|||
Line 83: | Line 83: | ||
| rOCCI is an OCCI 1.1 implementation for OpenNebula 3.x | | rOCCI is an OCCI 1.1 implementation for OpenNebula 3.x | ||
|} | |} | ||
== Cloud Brokering Solutions == | |||
=== Compatible ONE === | |||
* Compatible One is a complete plattform, with its own user management, accounting and monitoring, so it overlaps in some aspects with the ongoing work. | |||
* It does not expose an OCCI api, the user has to write its own XML files and send them to the broker. | |||
* The credentials for each of the connectors and providers have to be configured in advance by the administrator of the broker service. | |||
* The user has to specify in the manifests the cloud account that he wants to use, and the specific name of the image in the site. It seems that the purpose of CompatibleONE is to deploy and take care of a complete manifest description: A user wants 3 machines of type A in site FOO, and 2 machine of type B in site BAR, so he explicitly defines it in his manifests and CompatibleOne will deploy it on them. |
Revision as of 12:25, 18 December 2012
Main | Roadmap and Innovation | Technology | For Users | For Resource Providers | Media |
Leader: Alvaro Simon, JR1
Collaborators
Role | Institution | Name |
---|---|---|
Collaborator | OeRC | Matteo Turilli |
Collaborator | BSC | Daniele Lezzi |
Scope
This workgroup deals with the issues around cloud brokering. With 10+ resource providers lined up to be federated into the EGI cloud testbed, users need effective ways to access cloud resources. The goal is for a user to have a choice between a unified, abstracted view of the cloud testbed as a whole and the opportunity to target specific providers for their needs. As a consequence, this workgroup is concerned with both brokers and OCCI clients.
Roadmap
- Collect information about existing solutions for cloud brokering compatible with the OCCI and CDMI management interfaces;
- Collect information about existing solutions for OCCI and CDMI clients;
- Make an inventory of the available solutions;
- Choose a broker and a client for the testbed;
- If possible, join the development teams of the chosen solutions to the task force;
- Coordinate with the TF Resorce Providers to deploy the chosen solutions;
- Extend the demo testbed addressing a real-life use case.
Clients Comparison Table
Client/API | URL | OS | Suppport | OCCI/CDMI | Functionalities | Effort required | Comments |
---|---|---|---|---|---|---|---|
Hybridfox | http://code.google.com/p/hybridfox/ | Win/OS X/Linux | AWS/Eucalyptus/OpenStack/OpenNebula/HP Cloud | NO | Manage Images/Instances/Elastic IPs/Security Groups/Key-pairs | Low | Hybridfox does not support x509 auth, it uses EC2 auth for OpenNebula and OpenStack |
DeltaCloud | http://deltacloud.apache.org | Win/OS X/Linux | EC2/Eucalyptus/OpenStack/OpenNebula/vSphere | NO | Create/Start/Stop/Reboot/Destroy instances | Medium | DeltaCloud uses its own delta-cloud driver for each framework instead of OCCI. It provides storage support for S3, Warlus, Azure and Google Storage. |
Aeolus | http://aeolusproject.org/about.html | Win/OS X/Linux | Same as DeltaCloud | NO | Create/Start/Stop/.. instances. Manage different instances and Images from different private, public, or hybrid cloud providers. | Medium | Aeolus uses DeltaCloud cross-cloud abstraction library and it includes some extra functionalities. It includes Aeolus Conductor/Composer/Orchestrator/HA Manager |
rOCCI (API) | http://dev.opennebula.org/projects/ogf-occi | Linux | OpenNebula/EC2 | YES | Create/Start/Stop/Reboot/Destroy instances. Upload and register an image. Network conf. x509 auth. | Low | rOCCI is an OCCI 1.1 implementation for OpenNebula 3.x |
Cloud Brokering Solutions
Compatible ONE
- Compatible One is a complete plattform, with its own user management, accounting and monitoring, so it overlaps in some aspects with the ongoing work.
- It does not expose an OCCI api, the user has to write its own XML files and send them to the broker.
- The credentials for each of the connectors and providers have to be configured in advance by the administrator of the broker service.
- The user has to specify in the manifests the cloud account that he wants to use, and the specific name of the image in the site. It seems that the purpose of CompatibleONE is to deploy and take care of a complete manifest description: A user wants 3 machines of type A in site FOO, and 2 machine of type B in site BAR, so he explicitly defines it in his manifests and CompatibleOne will deploy it on them.