readme.txt

== 1st Adaptation Phase (customer B increases workload)==

The first adaptation phase is triggered because customer B has increased its workload which will lead to an SLA violation. The adaptation framework and the modeled adaptation process can be used to find a new system configuration as follows:

* Check if the paths to the model files are correct
* Set event in the by-multiple_customers.properies file to WorkloadUpdate-CustomerB (This event indicates that customer B has increased its workload) 
* Set latestObservation in the performance data repository by-multiple_customers.pdr to observations.0 (latestObservation="//@observations.0"). This is necessary because performance data is stored in the repository.
* Start adaptation with 
   java -jar <path/to/your/adaptation_framework.jar> by-multiple_customers.properties
* Check the results. The resource landscape model by.resourcelandscape should show one more prediction server instance for customer B (PS_CustB).

== 2nd Adaptation Phase (SLA of customer A violated) ==

Since the workload of customer B increased and required a new prediction server instance, the SLA of customer A are violated. We can use the adaptation framework to solve this as follows:

* Set event.type in the by-multiple_customers.properies file to SLAviolated-CustomerA (indicates SLA violation)
* Set latestObservation in by-multiple_customers.pdr to latestObservation="//@observations.1". This observation contains the measurements for the system configuration which resulted from the previous adaptation. This has to be adjusted manually since currently the adaptation framework is based on the performance data repository. This step is obsolete as soon as the prediction module is ready.
* Start adaptation with 
   java -jar <path/to/your/adaptation_framework.jar> by-multiple_customers.properties
* Check the results. The resource landscape model should now have an additional prediction server instance for customer A. Both instances are deployed on a separate machine (desc4).