CompatibleOne provides an implementation of the OCCI server in C. You can also see all the OCCI-based services and interfaces that CompatibleOne supports. CompatibleOne has a clear focus on the need of interoperability in the Cloud and so uses OCCI.
The Storage Networking Industry Association’s Cloud Storage Initiative (SNIA CSI) and the Open Grid Forum (OGF) are conducting the second in a series of international cloud plugfests slated for 2012.
Cloud Plugfest sponsored by SNIA CSI/OGF
June 14 – June 17, 2012 Where: Shenzhen, CN (Asia) Amsterdam, NL (Europe) Chicago, Illinois (North America)
All cloud implementers are invited to participate either in person or remotely. Participants need not be members of the SNIA, CSI or OGF and the cost to attend is FREE!*
The cloud plugfest will offer a highly collaborative, vendor-neutral, environment for developers and vendors to perform interoperability testing of CDMI and OCCI implementations. By attending the cloud plugfest participants will:
- Gain a greater understanding of what the needs are for establishing better interoperability with Cloud Computing and Cloud Storage standards, and the opportunity to refine those standards.
- Gain a better understanding of the requirements for interoperability integration between Cloud Storage (CDMI) and Cloud Computing (OCCI)
- Interact directly with cloud implementers and early adopters of CDMI and OCCI
How to register?
The cost to register is free. Visit the cloud plugfest page for additional details.
* Plugfest registration is free. Attendees are responsible for all other costs (travel, meals, etc.) associated with participating in this event including any participation fees imposed by co-located venues or event sponsors. For questions or comments about the SNIA Cloud Storage Initiative or this plugfest, please contact Tom Mancuso at csimanager – at – snia.org.
A team in Engineering (partially funded by Venus-C) have released a tool, ovf4one, which provides an OCCI interface that accepts OVF and provisions resources through the OpenNebula OCA interface. It is implemented in Java and implements the OCCI specifications and uses OVF messages and OpenNebula as backend.
From a technical perspective, ovf4one is an OCCI to OCA gateway, translating RESTful OCCI calls into OCA RESTful calls and the OVF XML message is translated into OpenNebula VM templates. This project has been realised as part of Venus-C EU project.
We blogged previously about the availability of an OCCI implementation for OpenStack. Below is a screen cast that demonstrates some, not all, of the functionality available.
Hot on the heels of the OCCI OpenStack implementation (wiki, code review) a number of our community members (big thanks to Eugene from R2AD) will be organising an OpenStack Design Summit unconference OCCI session. All are welcome to it from the inquisitive to the sceptical!
Topics to be discussed include:
- What is OCCI and its goals?
- Where does OCCI fit the OpenStack picture?
- How should OpenStack address “extra” APIs?
OCCI has been successfully mapped and implemented upon the Amazon EC2 API. The work has been carried out by TU Dortmund University in cooperation with the compute and research center GWDG. The implementation uses the rOCCI framework – more on that in a later post!
Today, we are happy and proud to find the German Federal Minstry of Economics and Technology (BMWi) fully endorses OCCI in its freshly published analysis on “The Standardisation Environment for Cloud Computing”.
This is a big vote of confidence in our work which was echoed by the UK G-Cloud report. Being picked up by the German government is obviously kudos to the community’s work, especially as it shows OCCI as a leader of current Cloud standardisation activities.
Lately, OCCI has received a lot of attention: the leading open-source cloud computing software stack implements it, a commercially focused project and related companies builds its whole ecosystem around it, the largest eInfrastructure provider in Europe endorses it, and many other things are ongoing around it.
The study identifies 19 standardisation organisations as “leading”, among which well-known international ones such as ISO, NIST, SNIA, and DMTF are listed next to OGF, the home of OCCI, and other European ones, such as ETSI and BITKOM.
Regarding standards, the report features “20 prototypical cloud standards [that] serve as models, […] and are greatly respected by experts”. Looking at this in detail, it is hugely encouraging to see that OCCI is considered to be the one with the greatest importance (together with OpenStack, which is on the way of speaking OCCI as well, and OAuth, which is orthogonal): the matrix above shows the classification by Booz and Partners on behalf of the BMWi. If you take a look on the upper right, you’ll find that OCCI is not only the one with the greatest maturity and quality, but also has the highest dissemination potential!
The report makes an analysis from the European and German point of view, and discusses the current field of standardisation in the Cloud arena. Stating that “the standardisation environment for cloud computing is only just starting to develop”, the report identifies OCCI (next to OVF, OpenStack, and CDMI) as “proving attractive”. It features a taxonomy of standards in cloud computing along challenges they address (“why?”) and the basis of their approach (“how?”), and identifies nine challenges, with data privacy the most prevalent, next to three fields (technology, management, and legal).
Well done to all and thanks to Alexander for the article and translations!
OpenStack is one of the major players in the cloud community at the moment. Still it currently lacks an standardized Interface which can be used to manage VMs. This changes now! During the Cloud Plugfest OCCI has been demoed on top of OpenStack.
Andy Edmonds presented the following slides during the Cloud Plugfest in Düsseldorf which highlight more details of the OCCI interface for OpenStack
Interoperability is key belief in OCCI. The OCCI specifications set out in text how to implement the API and formats, however it is still up to our community and adopters to implement this. It is often the case when implementing a specification certain implementation decisions made can have an impact on an implementations interoperability. It is for this reason why this ANTLR grammar has been created (thanks to SLA@SOI) to aid developers in creating their parser. The ANTLR grammar specifies the text rendering format in an abstract language known as a grammar.
The grammar defined, when used with the ANTLR tools, will generate a lexer and parser that will validate any valid OCCI text format. The grammar itself does not currently check whether a value associated with an attribute is valid. Rather it primarily ensures that the structure of the request is valid. It is still up to the implementer that service behaviours (e.g. correctly responding to HTTP GETs) are implemented correctly.
One of the key strengths of ANTLR, outside of its lexer/parser technology, is it has a wide range of target languages (18), so your favourite language has a good chance! This is an important advantage as this enables multiple implementations of OCCI (client or server) to all share a the same rules that parse the OCCI text format, regardless of language.
There are two grammars currently defined, one based on the other:
- occi-antlr-grammar: this solely defines the grammar and does not contain any target language specifics. It can be used as the foundation of target language specific OCCI grammars. An example of this extension is the occi-antlr-java. This grammar can generate lexer and parsers, however they will only validate the input and not extract values from the supplied input. If extracted values are required, a very common case, then the occi-antlr-java grammar gives an example of this.
- occi-antlr-java: this extends occi-antlr-grammar to include target language specifics. The target language used is Java. In this grammar file there are Java-specific ANTLR actions that extract the values from a valid OCCI text request/responses.
- occi-antlr-ruby: this just like occi-antlr-java extends the occi-antlr-grammar to include ruby language specifics. This was contributed by GWDG.
There are a number of rules that are present within the OCCI grammar that can be reused in order to validate certain supplied values. This would describe a second pass parsing phase. In the case that an implementer would like to validate a URI value then they can do so by using this URI grammar.
The following presentation also goes through some details related to ANTLR and the OCCI grammar.
We hope you find this useful! If there are any problems, issues or suggestions open a ticket.
The OCCI HTTP Rendering specification defines how to interact with the OCCI Core Model using the RESTful OCCI API. The document defines how the OCCI Core Model can be communicated with and thus serialised using the HTTP protocol via RESTful semantics.
Thanks to all that contributed content and reviews!