Evolution of the Open Cloud Computing Interface
Total Page:16
File Type:pdf, Size:1020Kb
Evolution of the Open Cloud Computing Interface Boris Parak´ 1, Zdenekˇ Sustrˇ 1, Michal Kimle1, Pablo Orviz Fernandez´ 2, Alvaro´ Lopez´ Garc´ıa2, Stavros Sachtouris3 and V´ıctor Mendez´ Munoz˜ 4 1Department of Distributed Computing, CESNET z.s.p.o, Zikova 4, Prague, Czech Republic 2Instituto de F´ısica de Cantabria (CSIC-UC), Avda. de los Castros s/n, Santander, Spain 3Greek Research & Technology Network, Mesogion Av. 56/11527, Athens, Greece 4Computer Architecture & Operating Systems Department, Universitat Autonoma` de Barcelona, Bellaterra, Spain Keywords: Cloud, Standards, Architecture, Interoperability, Management, OCCI. Abstract: The OCCI standard has been in use for half a decade, with multiple server-side and client-side implemen- tations in use across the world in heterogeneous cloud environments. The real-world experience uncovered certain peculiarities or even deficiencies which had to be addressed either with workarounds, agreements be- tween implementers, or with updates to the standard. This article sums up implementers’ experience with the standard, evaluating its maturity and discussing in detail some of the issues arising during development and use of OCCI-compliant interfaces. It shows how particular issues were tackled at different levels, and what the motivation was for some of the most recent changes introduced in the OCCI 1.2 specification. 1 INTRODUCTION (Nyren´ et al., 2011) 2. GFD.184 – OCCI Infrastructure The Open Cloud Computing Interface (OCCI) is a (Metsch and Edmonds, 2011b) RESTful protocol and API for a variety of manage- ment tasks. OCCI was originally designed to cre- 3. GFD.185 – OCCI HTTP Rendering ate a remote management API for IaaS (Infrastruc- (Metsch and Edmonds, 2011a) ture as a Service) model-based services, allowing However, the abstract and minimalistic nature of for the development of inter-operable tools for com- OCCI has its disadvantages. Most notably, signifi- mon tasks including deployment, autonomous scal- cant parts of the standard require careful interpreta- ing, and monitoring of virtual machines and related tion when creating a real-world implementation. This resources (Metsch and Edmonds, 2011b). often leads to incompatibilities between implemen- Since its publication in April 2011, OCCI has tations provided by different developers. This paper been adopted by a variety of cloud, cloud-like and is an attempt to briefly introduce popular implemen- cloud-adjacent platforms as the interoperability in- tations of OCCI (Section 2), collect as much feed- terface of choice. The strength of OCCI lies in its back from their developers as possible, describe most well though out and rather abstract core specifica- commonly encountered issues based on the aforemen- tion (Nyren´ et al., 2011) resembling more a mod- tioned feedback (Section 3), and propose solutions eling language than a communication protocol. It wherever possible either by referencing the upcoming gives OCCI its extensibility and wide-range applica- OCCI 1.2 standard (a set of not yet published docu- bility. Every other part of OCCI builds on top of ments, which have been, however, made available for the core specification by proposing various extensions public comment during 2015) or by suggesting future targeting specific areas such as infrastructure manage- improvements (Section 4). Finally, Section 5 makes ment, monitoring, accounting, over-the-wire render- an overall statement on the suitability and maturity of ing, transport protocol, billing, and many others. OCCI as it stands today. The OCCI standard specification currently (in ver- sion 1.1) consists of three separately published docu- ments: 1. GFD.183 – OCCI Core 339 Parák, B., Šustr, Z., Kimle, M., Fernández, P., García, Á., Sachtouris, S. and Muñoz, V. Evolution of the Open Cloud Computing Interface. In Proceedings of the 6th International Conference on Cloud Computing and Services Science (CLOSER 2016) - Volume 2, pages 339-346 ISBN: 978-989-758-182-3 Copyright c 2016 by SCITEPRESS – Science and Technology Publications, Lda. All rights reserved OCCI 2016 - Special Session on Experiences with OCCI 2 IMPLEMENTATIONS such as Collection or Model, simplifying the han- dling and rendering of complex OCCI messages, pro- Over the last five years, OCCI gained multiple experi- vides advanced logging and attribute validation facil- mental and production-grade implementations in vari- ities. Using Ruby’s meta-programming techniques, ous states of usability. These implementations helped the core is able to “extend itself” with new classes and the overall evolution of the standard and contributed definitions provided dynamically at run-time. This to the work being done by the OGF OCCI Working works well with OCCI’s inherent extensibility. Group on the OCCI 1.2 standard. The following sec- rOCCI-api builds on top of rOCCI-core and im- tions briefly describe the most prominent or widely plements support for transport protocols and corre- used open-source OCCI implementations whilst also sponding authentication methods. It also provides an mentioning particular development challenges. This extended set of various helpers simplifying the use of list is by no means all-encompassing; it is meant to rOCCI-core and targeting the development of client- provide a quick overview. The implementations listed side applications and tools. HTTP (Fielding and Get- here are also closely related to EGI and EGI Federated tys, 2014) is currently the only supported transport Cloud (del Castillo et al., 2015) due to existing affili- protocol. ations of involved authors. Other prominent projects rOCCI-api also implements a pluggable authen- and implementations of OCCI not mentioned in this tication mechanism capable of fall-backs. Every au- section include OCCIware (OCCIware Consortium, thentication plug-in can declare a set of alternatives 2016), erocci (Parpaillon, 2016), and pyssf (Metsch, to be used in case of failure. This concept is capable 2016). Readers are hereby encouraged to explore of masking differences between various cloud frame- these as well. works implementing OCCI using their own authenti- cation schemes. 2.1 The rOCCI Framework rOCCI-cli, built on top of rOCCI-api, serves as an end-user client providing a shell-based in- The rOCCI framework, originally developed by terface. It allows users to interact with OCCI- GWDG, later adopted and now maintained by CES- compliant interfaces and perform basic operations NET, was written to simplify implementation of the and actions. Similarly, rOCCI-server, built on top of OCCI 1.1 protocol in Ruby and later provided the rOCCI-core, provides a server-side implementation base for working client and server components giving supporting multiple cloud management frameworks OCCI support to multiple cloud platforms while en- or public cloud providers as its back-ends, expos- suring interoperability with other existing implemen- ing their resources via an OCCI-compliant interface. tations (Parak´ et al., 2014). It currently supports OpenNebula (The OpenNebula At the time of writing this paper, the rOCCI Project, 2016) and Amazon Web Services EC2 (Ama- framework has two published components: zon Web Services, Inc., 2016), with plans to imple- rOCCI-core and rOCCI-api. These serve as ment support for Microsoft Azure (Microsoft, 2016). the base for two end-user products: rOCCI-cli and The most notable challenges encountered whilst rOCCI-server. implementing parts of the rOCCI framework were, in The initial server-side component provided basic no particular order, the plain-text rendering, the lack functionality and served as a proof of concept when it of clear authentication guidelines, missing parts of was adopted by the EGI Federated Cloud Task Force the attribute model, and vague (side-)effect descrip- and was chosen to act as the designated virtual ma- tions for the infrastructure extension. The following chine management interface (Wallom et al., 2015). paragraphs will briefly address each of these issues in This led to further funding from the EGI-InSPIRE greater detail. project, development of a full featured client and a Implementing a plain-text-based rendering of a new rOCCI-server suitable for production environ- non-trivial protocol is always a challenge. The un- ment. structured nature of a plain text requires customized rOCCI-core is a central component of the frame- regular expressions or state machines for extract- work. It implements classes representing entities de- ing relevant information. It also prevents the devel- fined by the OCCI standard, provides parsing and oper from using existing well-tested parsers or seri- rendering capabilities to/from multiple message for- alization and de-serialization libraries. Writing cus- mats. Currently supported, as both input and output tomized parsers is always time-consuming and prone formats, are plain-text and JSON which is based on to errors, which are difficult to discover. an early draft of OCCI 1.2 JSON rendering (not yet The lack of clear authentication guidelines is a published). It also introduces various helper classes feature of the OCCI standard. It simply points the 340 Evolution of the Open Cloud Computing Interface reader to mechanisms appropriate (and standardized) adaptor which will expose an interface for submitting for the given transport protocol, which helps to keep grid jobs into automatically provisioned virtual ma- the standard extensible. However, it makes the im- chines in OCCI-compliant clouds. Another project plementation of working OCCI-enabled components utilizing