Difference between revisions of "Fedcloud-tf:WorkGroups:Scenario1"
Line 150: | Line 150: | ||
|- | |- | ||
|rowspan="11" style="text-align:left;"|Triggering basic actions on resources | |rowspan="11" style="text-align:left;"|Triggering basic actions on resources | ||
| Compute – start | | style="text-align:left;"| Compute – <code>start</code> | ||
| style="background-color:lightgreen;"| OK | | style="background-color:lightgreen;"| OK | ||
| style="background-color:lightgreen;"| OK | | style="background-color:lightgreen;"| OK | ||
Line 157: | Line 157: | ||
| | | | ||
|- | |- | ||
| Compute – stop | | style="text-align:left;"| Compute – <code>stop</code> | ||
| style="background-color:lightgreen;"| OK | | style="background-color:lightgreen;"| OK | ||
| style="background-color:lightgreen;"| OK | | style="background-color:lightgreen;"| OK | ||
Line 164: | Line 164: | ||
| | | | ||
|- | |- | ||
| Compute – restart | | style="text-align:left;"| Compute – <code>restart</code> | ||
| style="background-color:lightgreen;"| OK | | style="background-color:lightgreen;"| OK | ||
| style="background-color:lightgreen;"| OK | | style="background-color:lightgreen;"| OK | ||
Line 171: | Line 171: | ||
| | | | ||
|- | |- | ||
| Compute – suspend | | style="text-align:left;"| Compute – <code>suspend</code> | ||
| style="background-color:lightgreen;"| OK | | style="background-color:lightgreen;"| OK | ||
| style="background-color:lightgreen;"| OK | | style="background-color:lightgreen;"| OK | ||
Line 178: | Line 178: | ||
| | | | ||
|- | |- | ||
| Storage – online | | style="text-align:left;"| Storage – <code>online</code> | ||
| style="background-color:lightgreen;"| OK | | style="background-color:lightgreen;"| OK | ||
| style="background-color:#ff7777;"| NO | | style="background-color:#ff7777;"| NO | ||
Line 185: | Line 185: | ||
| | | | ||
|- | |- | ||
| Storage – offline | | style="text-align:left;"| Storage – <code>offline</code> | ||
| style="background-color:lightgreen;"| OK | | style="background-color:lightgreen;"| OK | ||
| style="background-color:#ff7777;"| NO | | style="background-color:#ff7777;"| NO | ||
Line 192: | Line 192: | ||
| | | | ||
|- | |- | ||
| Storage – backup | | style="text-align:left;"| Storage – <code>backup</code> | ||
| style="background-color:lightgreen;"| OK | | style="background-color:lightgreen;"| OK | ||
| style="background-color:#ff7777;"| NO | | style="background-color:#ff7777;"| NO | ||
Line 199: | Line 199: | ||
| | | | ||
|- | |- | ||
| Storage – snapshot | | style="text-align:left;"| Storage – <code>snapshot</code> | ||
| style="background-color:lightgreen;"| OK | | style="background-color:lightgreen;"| OK | ||
| style="background-color:lightgreen;"| OK | | style="background-color:lightgreen;"| OK | ||
Line 206: | Line 206: | ||
| | | | ||
|- | |- | ||
| Storage – resize | | style="text-align:left;"| Storage – <code>resize</code> | ||
| style="background-color:lightgreen;"| OK | | style="background-color:lightgreen;"| OK | ||
| style="background-color:#ff7777;"| NO | | style="background-color:#ff7777;"| NO | ||
Line 213: | Line 213: | ||
| | | | ||
|- | |- | ||
| Network – up | | style="text-align:left;"| Network – <code>up</code> | ||
| style="background-color:lightgreen;"| OK | | style="background-color:lightgreen;"| OK | ||
| style="background-color:#ff7777;"| NO | | style="background-color:#ff7777;"| NO | ||
Line 220: | Line 220: | ||
| | | | ||
|- | |- | ||
| Network – down | | style="text-align:left;"| Network – <code>down</code> | ||
| style="background-color:lightgreen;"| OK | | style="background-color:lightgreen;"| OK | ||
| style="background-color:#ff7777;"| NO | | style="background-color:#ff7777;"| NO |
Revision as of 17:54, 5 February 2015
Main | Roadmap and Innovation | Technology | For Users | For Resource Providers | Media |
Scenario 1: Virtual Machine Management
Role | Institution | Name |
---|---|---|
Scenario leader | CESNET | Boris Parák |
Collaborator | CESNET | Zdeněk Šustr |
Collaborator | GWDG | Piotr Kasprzak |
Collaborator | IFCA | Enol Fernández |
Collaborator | GRNET | Kostas Koumantaros |
Activities
Ongoing Issues
Interoperability
Authentication
Deployment
Support for new platforms & public providers
Available Open Standards
OCCI
Developed by the Open Grid Forum, OCCI is a boundary protocol and API that acts as a service front-end to a provider’s internal management framework by exposing its resources. As of this writing (early 2015) the specification consist of three documents:
- OCCI Core describing the formal definition of the the OCCI Core Model
- OCCI Infrastructure defining the OCCI Infrastructure extension for the IaaS domain, defining additional resource types, their attributes and the actions that can be taken on each resource type
- OCCI HTTP Rendering defining interaction with the OCCI Core Model using the RESTful OCCI API
The OCCI Working Group is also working on additional specification, currently in various stages of progress:
- OCCI XML Rendering
- OCCI JSON Rendering
- OCCI Billing and Monitoring
- OCCI PaaS extension
- OCCI SLAs extension
CIMI
The Cloud Infrastructure Management Interface is a standard released by DMTF. Similarly to OCCI, it also consists of multiple specifications:
- CIMI Primer (DSP2027) v. 1.0.0
- CIMI (DSP0263) v. 1.1.0
- CIMI-CIM (DSP0264) v. 1.0.0
CIMI is a highly specific IaaS protocol, defining a wide range of attributes applicable in the context of IaaS. This is what mainly distinguishes it from OCCI, which is a much more light-weight, generic boundary-level protocol, relying on its extensibility to cover specific areas.
OGF's Open Cloud Computing Interface
OCCI was selected for the FedCloud environment for multiple reasons, chief among them its simplicity and the fact that other standards of that kind (such asi CIMI) have not been published until well after the initiative started.
Available OCCI implementations
Server
rOCCI-server
rOCCI-server, part of the rOCCI Framework, is a stand-alone service providing "translation" between OCCI and proprietary cloud management frameworks, which are not otherwise OCCI-compatible. Individual types of clod management framework are provided through specific backends. The list of currently available backends is available in the ROCCI-server_Backend_development_status page.
rOCCI-server can be obtained as source from GitHub or in the form of packages from EGI's AppDB.
Common documentation for the whole rOCCI framework is available at the EGI Wiki.
OCCI-OS
OCCI-OS provides a python egg which can be easily deployed in OpenStack and will thereby add OCCI support and interface to OpenStack. Available and documented at [1].
snf-occi
snf-occi implements the OCCI specification and maps it to the Synnefo OpenStack API, so it acts as a translation bridge between OCCI and Synnefo, providing an OCCI compatibility layer. [2]
Client
rOCCI-cli
rOCCI-cli, another part of the rOCCI Framework, is a command-line client capable of communicating with any OCCI-enabled server. It supports several methods of authentication, including X.509 certificates and proxy certificates.
rOCCI-cli can be obtained as source from GitHub or in the form of packages from EGI's AppDB.
Common documentation for the whole rOCCI framework is available at the EGI Wiki.
Library
rOCCI-core and rOCCI-api
Core parts of the rOCCI framework, the rOCCI-core library implements the OCCI class structure in Ruby, which allows developers to work with OCCI concepts natively. rOCCI-api takes care of transporting OCCI messages, currently supporting HTTP as the only transport protocol.
pyssf
pyssf is a set of python modules developed by Platform Computing, man contributors to the OCCI standard. Source as well as documentation is available from GitHub [3].
jOCCI-core and jOCCI-api
jOCCI is an independent OCCI implementation by the authors of rOCCI. It satisfies the demand for a Java library, replacing the previous alternative based on JRuby. Currently in development, is is available as source from Github [4] [5].
Interoperability Table
Main tasks identified in Scenario1, supported by various server-side OCCI implementations.
Task | Subtask | rOCCI-server | OCCI-OS OpenStack |
snf-occi Synnefo | ||
---|---|---|---|---|---|---|
OpenNebula | AWS | MS Azure | ||||
Creating VMs | OK | OK | OK | OK | OK | |
Querying VMs | OK | OK | OK | OK | OK | |
Destroying VMs | OK | OK | OK | OK | OK | |
Triggering basic actions on resources | Compute – start
|
OK | OK | |||
Compute – stop
|
OK | OK | ||||
Compute – restart
|
OK | OK | ||||
Compute – suspend
|
OK | OK | ||||
Storage – online
|
OK | NO | ||||
Storage – offline
|
OK | NO | ||||
Storage – backup
|
OK | NO | ||||
Storage – snapshot
|
OK | OK | ||||
Storage – resize
|
OK | NO | ||||
Network – up
|
OK | NO | ||||
Network – down
|
OK | NO | ||||
Creating block storage | OK | OK | ||||
Destroying block storage | OK | OK | ||||
Attaching block storage to VMs | Attaching storage on VM creation | OK | OK | |||
Attaching storage while VM exists | OK | OK | ||||
Detaching block storage from VMs | OK | OK | ||||
Attaching network interfaces to VMs | OK | OK | ||||
Detaching network interfaces from VMs | OK | OK | ||||
Using contextualization to modify VMs on boot | OK | OK | ||||
Attaching storage or networks on boot (in-line links) | OK | OK |