Mocci is an extension for the Open Cloud Computing Interface (OCCI) to enable a model-driven management of monitoring instruments in the cloud, as well as storing their results within an OCCI runtime model.
Together with other tools from the OCCI ecosystem it provides a testing and execution environment for self-adaptive systems.
In addition to the getting started and the example scenarios discussed in this document, the main components of MOCCI are represented by the:
MOCCI is an extension for the [Open Cloud Computing Interface (OCCI)](http://occi-wg.org/about/specification/) to enable a model-driven management of monitoring devices in the cloud, as well as storing their results within an OCCI-compliant runtime model. Together with other tools from the OCCI ecosystem it provides a testing and execution environment for self-adaptive systems.
In the following you will find a getting started guide in which a preconfigured virtualbox image is downloaded to perform example scenarios and an tutorial on how to enrich existing OCCI models with monitoring functionality.
Moreover, an introduction to MOCCI's components is provided, as well as links and description on how to integrate MOCCI with other pre-existing tooling from the OCCI ecosystem.
## Getting Started
To getting started with MOCCI we provide a hands on experience in form of a virtualbox image in which everything required is already configured and ready to go.
To get started with MOCCI we provide a hands on experience in form of a virtualbox image in which everything required is already configured and ready to go.
Alternatively, to manually setup the single components instructions can be found at the end of this document.
### VirtualBox
To get a quick start in the OCCI ecosystem and the MOCCI monitoring extension download the following VM image. This image contains a version of OCCI-Studio with the MoDMaCAO and MOCCI plugins pre-installed.
Moreover, it contains a checked out version of MOCCI and a local version of the MARTserver.
### Download VirtualBox Image
To get a quick start into MOCCI download the VM image located here:
This image contains a version of OCCI-Studio with the MoDMaCAO and MOCCI plugins pre-installed.
Moreover, it contains a checked out version of MOCCI and a local version of the MARTserver using dummy connectors.
After the download has finished, open Virtualbox and import the virtual appliance:
1. Click on File->Import Appliance...
...
...
@@ -34,26 +30,39 @@ Next start the virtual machine:
1. Choose the recently imported VM and press Start.
2. The username, and password are both: mocci
## Step-by-step example scenarios
To get the ropes of MOCCI, we provide step-by-step instructions for three example scenarios, which are based on the same initial deployment model.
### Execute Step-by-step example scenarios and tutorials
To learn the ropes of MOCCI, we provide step-by-step instructions for three example scenarios, which are based on the same initial deployment model.
1.[Initial Deployment](doc/initial.md): This tutorial demonstrates how to deploy an initial cloud application getting monitored by MOCCI.
2.[Vertical Scaling](doc/vertical.md): This scenario scales a VM in the initial deployment up and down according to its CPU utilization.
3.[Horizontal Scaling](doc/horizontal.md): This scenario dynamically adds and releases worker nodes in the hadoop cluster of the initial deployment.
4.[Sensor Creation](doc/own.md): This scenario shows how to add sensors to an OCCI model.
4.[Sensor Creation](doc/own.md): This tutorial shows how to add sensors to an OCCI model.
*Note:* Please note that the execution of the example scenarios in an distributed environment, e.g., requires access to it as well as connectors implementing how the differen requests should be handled.
Thus, the provided scenarios are based on monitoring data simulated by the [MOCCI connector dummy](https://gitlab.gwdg.de/rwm/de.ugoe.cs.rwm.mocci/tree/master/de.ugoe.cs.rwm.mocci.connector.dummy).
## MOCCI Components and Related Artifacts
MOCCI itself is a monitoring extension that in combination with pre-existing software from the OCCI ecosystem allows for an easy development and testing of self-adaptation engines for cloud systems.
This section provides an overview of MOCCI's components, as well as other tools used to develop and perform the example scenarios.
## OCCI-Studio and MoDMaCAO
### MOCCI
MOCCI consists of three main components. The metamodel extension for OCCI, a connector responsible to deploy, configure, and manage sensors and its monitoring devices in the cloud, and a dummy connector simulating user defined monitoring results for test purposes. Descriptions of the single components can be found via the following links:
In addition to the getting started and the example scenarios discussed in this document, the main components of MOCCI are represented by the:
[OCCI-Studio](https://github.com/occiware/OCCI-Studio) is an IDE providing many convenient tools to develop around OCCI. For example, it provides a model editor, graphically and textually. Moreover, it allows to design OCCI extensions and automatically generate code from it.
In addition to OCCI-Studio the [Model-Driven Configuration Management of Cloud Applications with OCCI (MoDMaCAO)](https://github.com/occiware/MoDMaCAO) extension suite is needed.
[Documentation on how to setup and configure OCCI-Studio](doc/studio.md)
[Documentation on how to setup and configure OCCI-Studio with MOCCI](doc/studio.md)
## MartServer
### MartServer
The [MartServer](https://github.com/occiware/MartServer) represents the OCCI interface to which requests are send in order to build and monitor the cloud application.
This server is easy to extend by plugging in connectors created for modeled OCCI extensions.
[Documentation on how to setup and configure the MartServer](doc/api.md)
*Note:* Please note that the execution of the example scenarios in an distributed environment requires access and connectors to the cloud.
Thus, the provided scenarios in the getting started VM is only executed based on monitoring data simulated by the [MOCCI connector dummy](https://gitlab.gwdg.de/rwm/de.ugoe.cs.rwm.mocci/tree/master/de.ugoe.cs.rwm.mocci.connector.dummy).
The sensor element represents a top level element used to easily manage all monitoring instruments it contains.
The containment relationship to its monitoring instruments is modeled via componentlinks.
The sensor element represents a top level element used to easily manage all monitoring devices it contains.
The containment relationship to its monitoring devices is modeled via componentlinks.
As sensor inherits application, it gains access to attributes reflecting its current state, as well as actions to manage its lifecycle.
Thus, the monitoring instruments can be deployed by accessing the sensor directly, but also by addressing each instrument separately.
Thus, the monitoring devices can be deployed by accessing the sensor directly, but also by addressing each device separately.
To specify the object a sensor monitors, it can be connected over a monitorableproperty to the corresponding resource.
The property itself defines two attributes defining the name of the property it monitors, and its results.
...
...
@@ -17,7 +17,7 @@ The property itself defines two attributes defining the name of the property it
## The Monitoring Components
Each monitoring component (datagatherer, dataprocessor, resultprovider) inherit from component.
Thus, each monitoring component gains access to actions to deploy, configure, start, stop, and undeploy it.
When not using the dummy connector, the execution of these actions trigger the execution of configuration management scripts linked to the individual monitoring instrument.
When not using the dummy connector, the execution of these actions trigger the execution of configuration management scripts linked to the individual monitoring device.
The name of the scripts are assigned over user mixins attached to the component, which is located in the roles folder of the MartServer.
To define where each monitoring instrument is deployed placementlinks are used connecting the instrument to the vm it is deployed on.
Thus, each instrument can be hosted by different vm.
\ No newline at end of file
To define where each monitoring device is deployed placementlinks are used connecting the device to the VM it is deployed on.
