Zdeněk Šustr

The rOCCI Project - Providing Cloud Interoperability with OCCI 1.1

OCCI (Open Cloud Computing Interface) is an open protocol for management of tasks in the cloud environment focused on integration, portability and interoperability with a high degree of extensibility. It is designed to bridge differences between various cloud platforms and provide common ground for users and developers alike. The rOCCI framework, originally developed by GWDG, later adopted and now maintained by CESNET, was written to simplify implementation of the OCCI 1.1 protocol in Ruby and later provided the base for working client and server com- ponents giving OCCI support to multiple cloud platforms while ensuring interoperability with other existing implementations. The initial server-side component provided basic functionality and served as a proof of concept when it was adopted by the EGI Federated Cloud Task and was chosen to act as the designated virtual machine management interface. This led to further funding from the EGI-InSPIRE project, development of a full featured client and a new rOCCI-server suitable for production environment. It has also prompted further proliferation of the OCCI pro- tocol, spawned multiple connector/backend implementations and provided developers with valu- able feedback and opportunities to test their own implementations of the OCCI standard. This paper aims to provide basic information about the OCCI protocol, introduce its implementation in rOCCI, describe some of the core functionality provided by the rOCCI client and rOCCI-server along with their impact on interoperability in the cloud environment. It also briefly examines its use in the EGI Federated Cloud Task environment and explores the possibility of further integra- tion with other cloud platforms. All this with interoperability in mind. The paper also describes a carefully chosen subset of problems encountered whilst trying to provide interoperability with multiple cloud platforms through the use of the OCCI protocol, with real-world examples and chosen solutions

A uniform job monitoring service in multiple job universes

We describe an ongoing work of extending the gLite Logging and Bookkeeping (L&B) service to be able to track additional types of jobs, with the vision of being able to uniformly follow jobs on the Grid, even when they pass between different middleware domains. Details are given on the simpler case of PBS jobs, which prove the cababilityof L&B to deal with additional job types,as well as started more complex and challenging work on Condor jobs, where theimpact of eventual success is larger.

Experimental evaluation of job provenance in ATLAS environment

Grid middleware stacks, including gLite, matured into the state of being able to process up to millions of jobs per day. Logging and Bookkeeping, the gLite job-tracking service, keeps pace with this rate; however, it is not designed to provide a long-term archive of information on executed jobs. ATLAS — representative of a large user community — addresses this issue with its own job catalogue (ProdDB). Development of such a customized service, not easily reusable, took considerable effort which is not affordable by smaller communities. On the contrary, Job Provenance (JP), a generic gLite service designed for long-term archiving of information on executed jobs focusing on scalability, extensibility, uniform data view, and configurability, allows more specialized catalogues to be easily built. We present the first results of an experimental JP deployment for the ATLAS production infrastructure where a JP installation was fed with a part of ATLAS jobs, and also stress tested with real production data. The main outcome of this work is a demonstration that JP can complement large-scale application-specific job catalogue services, while serving a similar purpose where there are none available.

Multiple Ligand Trajectory Docking Study - Semiautomatic Analysis of Molecular Dynamics Simulations using EGEE gLite Services

Interactions between large biomolecules and smaller bio-active ligands are usually studied through a process called docking. Its aim is to find an energetically favorable orientation of a ligand within an active site of a biomolecule. Chemical reactions take place in active site and the role of the ligand is either to speed up, slow down or change the reaction (e.g., an enzyme catalyzed hydrolysis), which is why it can have huge pharmaceutical or other commercial impact. We present a tool that supports effective management and control of a typical workflow of docking parametric study. Selected subsets of ligands and protein trajectory snapshots can be displayed in three different views and further analyzed. Finally, the application supports spawning and steering underlying computations running on the grid.

Job Provenance --- Insight into Very Large Provenance Datasets

Following the job-centric monitoring concept, Job Provenance (JP) service organizes provenance records on the per-job basis. It is designed to manage very large number of records, as was required in the EGEE project where it was developed originally. The quantitative aspect is also a focus of the presented demonstration. We show JP capability to retrieve data items of interest from a large dataset of full records of more than 1 million of jobs, to perform non-trivial transformation on those data, and organize the results in such a way that repeated interactive queries are possible. The application area of the demo is derived from that of previous Provenance Challenges. Though the topic of the demo -- a computational experiment -- is arranged rather artificially, the demonstration still delivers its main message that JP supports non-trivial transformations and interactive queries on large data sets.

The-Rocci-Project/Rocci-Server V2.0.0.Beta.2

2017-09-15 Added CHANGELOG.md Catching OCCI Argument Errors during parsing Moved instance actions to async ActiveJobs Cleaned up old logging syntax Add onetoken util that creates cloud tokens