Skip to content
Snippets Groups Projects
Commit 64c87974 authored by erbel's avatar erbel
Browse files

Adjusted Readme

parent ff8774dc
No related branches found
No related tags found
No related merge requests found
Pipeline #88754 passed
# MOCCI # MOCCI
[![build status](https://gitlab.gwdg.de/rwm/de.ugoe.cs.rwm.mocci/badges/master/pipeline.svg)](https://gitlab.gwdg.de/rwm/de.ugoe.cs.rwm.mocci/commits/master) [![build status](https://gitlab.gwdg.de/rwm/de.ugoe.cs.rwm.mocci/badges/master/pipeline.svg)](https://gitlab.gwdg.de/rwm/de.ugoe.cs.rwm.mocci/commits/master)
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. This tooling also allows obtaining a snapshot of the EMF-based architecture runtime model in the (JSON format)[./doc/browser.png]. 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. The paper submitted to this artifact and the virtualbox image can be found [here](https://owncloud.gwdg.de/index.php/s/5u2ddnyyNlzecM5) with the password being mocci. 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. This tooling also allows obtaining a snapshot of the EMF-based architecture runtime model in the [JSON format](./doc/browser.png). 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. The paper submitted to this artifact and the virtualbox image can be found [here](https://owncloud.gwdg.de/index.php/s/5u2ddnyyNlzecM5) with the password being mocci.
## Getting Started ## Getting Started
......
...@@ -41,7 +41,7 @@ Execute: Deploying adjusted Model ...@@ -41,7 +41,7 @@ Execute: Deploying adjusted Model
In this case we queried for VMs with Critical and None CPU utilization. We detected only one being Critical. Thus, a critical state is detected for which an upscaling of the cluster is planned. Hereby, a compute node is added to the hadoop cluster with the ip 10.254.1.12, as well as the worker component hosted on this VM. Moreover, a Sensor including its monitoring devices are added to the model. These are responsible to monitor the newly added worker in the cluster. Before the changes get executed by putting the adjusted model into DOCCI, a model transformation is performed on it to add provider specific information to the model, e.g., an attachment of the new VM to the management network. In this case we queried for VMs with Critical and None CPU utilization. We detected only one being Critical. Thus, a critical state is detected for which an upscaling of the cluster is planned. Hereby, a compute node is added to the hadoop cluster with the ip 10.254.1.12, as well as the worker component hosted on this VM. Moreover, a Sensor including its monitoring devices are added to the model. These are responsible to monitor the newly added worker in the cluster. Before the changes get executed by putting the adjusted model into DOCCI, a model transformation is performed on it to add provider specific information to the model, e.g., an attachment of the new VM to the management network.
If more than one worker node is currently active in the cluster and a minimum of one has a CPU utilization of None the downscaling removes the VM with None utilization from the cluster. To investigate the expected behavior of this self-adaptive control loop you can check an example log [here]. This log also includes all REST requests performed against the OCCI interface. If more than one worker node is currently active in the cluster and a minimum of one has a CPU utilization of None the downscaling removes the VM with None utilization from the cluster. To investigate the expected behavior of this self-adaptive control loop you can check an example log [here](./horizontalLog.md). This log also includes all REST requests performed against the OCCI interface.
*Note*: If you want to get the same information as in the full log, including requests performed against the OCCI interface, you can alternatively start the MAPE_Exec_Info.jar. *Note*: If you want to get the same information as in the full log, including requests performed against the OCCI interface, you can alternatively start the MAPE_Exec_Info.jar.
......
0% Loading or .
You are about to add 0 people to the discussion. Proceed with caution.
Finish editing this message first!
Please register or to comment