Alert.png The wiki is deprecated and due to be decommissioned by the end of September 2022.
The content is being migrated to other supports, new updates will be ignored and lost.
If needed you can get in touch with EGI SDIS team using operations @ egi.eu.

Difference between revisions of "Fedcloud-tf:WorkGroups:Brokering"

From EGIWiki
Jump to navigation Jump to search
(Redirected page to Federated Cloud Brokering)
 
(22 intermediate revisions by 5 users not shown)
Line 1: Line 1:
{{Fedcloud-tf:Menu}} {{Fedcloud-tf:WorkGroups:Menu}} {{TOC_right}}
#REDIRECT[[Federated_Cloud_Brokering]]
 
<font color="red">Leader: Alvaro Simon, JR1 </font>
 
== Collaborators  ==
 
{| border="1"
|-
! 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  ==
 
{| width="90%" cellspacing="0" cellpadding="5" style="border:1px solid black;" class="wikitable"
|- style="background-color:darkgray;"
! Client/API
! URL
! OS
! Support
! OCCI/CDMI
! Functionalities
! Effort required
! Comments
|-
| Hybridfox
| http://code.google.com/p/hybridfox/
| Win/OS X/Linux
| AWS/Eucalyptus/OpenStack/OpenNebula/HP Cloud
| <span style="color:red"> '''NO'''</span>
| Manage Images/Instances/Elastic IPs/Security Groups/Key-pairs
| <span style="color:green"> '''Low'''</span>
| 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
| <span style="color:red"> '''NO'''</span>
| Create/Start/Stop/Reboot/Destroy instances
| <span style="color:orange"> '''Medium'''</span>
| 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
| <span style="color:red"> '''NO'''</span>
| Create/Start/Stop/.. instances. Manage different instances and Images from different private, public, or hybrid cloud providers.
| <span style="color:orange"> '''Medium'''</span>
| 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
| <span style="color:green"> '''YES'''</span>
| Create/Start/Stop/Reboot/Destroy instances. Upload and register an image. Network conf. x509 auth.
| <span style="color:green"> '''Low'''</span>
| rOCCI is an OCCI 1.1 implementation for OpenNebula 3.x
|}
 
== Cloud Brokering Solutions ==
 
=== Compatible ONE ===
{| width="90%" cellspacing="0" cellpadding="5" style="border:1px solid black;" class="wikitable"
|- style="background-color:darkgray;"
! Name
! URL
! Cloud SW Support
! OCCI
! Functionalities
! Effort required
! Comments
|-
| CompatibleOne
| http://www.compatibleone.org/
| OpenStack, OpenNebula, Azure, Vcloud
| Yes, supports OCCI, but implements his own OCCI interface for each of the stacks (PROCCI).
| Accounting, Brokering, User management, Monitoring.
| Medium
|
* 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.
 
|}

Latest revision as of 13:11, 8 June 2015