From cfde0e7f60cc90ce5ab1283ca021b70f40f5cea2 Mon Sep 17 00:00:00 2001
From: "Osaba Icedo, Eneko" <eneko.osaba@tecnalia.com>
Date: Wed, 19 Jul 2023 10:23:09 +0200
Subject: [PATCH] Update README.md
---
README.md | 48 ++++++++++++++++++++++++------------------------
1 file changed, 24 insertions(+), 24 deletions(-)
diff --git a/README.md b/README.md
index 8ea664d..4a89826 100644
--- a/README.md
+++ b/README.md
@@ -134,7 +134,7 @@ infrastructure and historical data, available from the IEC.
Having said that, in order to correctly run the optimization module, the following structure
should be added to the input DOML
-------------------------------------------------------------------------------------------------------------------------
+```
optimization opt {
objectives {
@@ -143,19 +143,19 @@ optimization opt {
}
}
-------------------------------------------------------------------------------------------------------------------------
+```
At this moment, three different objectives can be contemplated in the IOP: minimize the **cost**,
maximize the **availability** and maximize the **performance**. Any combination of these objectives
can be introduced. Here is an example of the full three objectives and how they should be introduced:
-------------------------------------------------------------------------------------------------------------------------
+```
objectives {
"cost" => min
"availability" => max
"performance" => max
}
-------------------------------------------------------------------------------------------------------------------------
+```
Regarding the non funcional requirements, different kind of requirements are contemplated in
the current version of the IOP, such as assign a maximum cost for the overall configuration, assign a minimum
@@ -163,7 +163,7 @@ availability for the overall configuration, assign a minimum performance for the
restrict the region of the selected elements and restrict the providers of the elements. Here is an
example of the five requirements, and how they should be introduced:
-------------------------------------------------------------------------------------------------------------------------
+```
nonfunctional_requirements {
req1 "Cost <= 200" max 200.0 => "cost";
req2 "Availability >= 94.0%" min 94.0 => "availability";
@@ -171,11 +171,11 @@ example of the five requirements, and how they should be introduced:
req4 "Region" values "Europe" => "region";
req5 "Provider" values "aws" => "provider";
}
-------------------------------------------------------------------------------------------------------------------------
+```
Thus, this could be a possible input for the IOP, represented in the input DOML.
-------------------------------------------------------------------------------------------------------------------------
+```
optimization opt {
objectives {
"cost" => min
@@ -187,29 +187,29 @@ optimization opt {
req3 "Region" values "Europe" => "region";
}
}
-------------------------------------------------------------------------------------------------------------------------
+```
A special attention should be made here to the multi-element optimization. In order to contemplate the multi-element
optimization, the user can introduce the following structure as a new requirement:
-------------------------------------------------------------------------------------------------------------------------
+```
nonfunctional_requirements {
req1 "elements" => "";
}
-------------------------------------------------------------------------------------------------------------------------
+```
Using this structure, the use is able to introduce the combination of elements he/she is searching for. For example, if
the user needs to deploy a service with 3 different virtual machines and 1 database, the element part should be:
-------------------------------------------------------------------------------------------------------------------------
+```
nonfunctional_requirements {
req1 "elements" => "VM VM VM Database";
}
-------------------------------------------------------------------------------------------------------------------------
+```
That is, the elements requirement should be introduced as a list of Strings, being VM the acronym of Virtual Machine. In
order to facilitate the usage of this multi-optimization feature, several aspects should be taken into account:
@@ -219,7 +219,7 @@ order to facilitate the usage of this multi-optimization feature, several aspect
storages, he/she can define the elements part without adapting to any established order. In other words, the following
three examples represent the same situation above mentioned:
-------------------------------------------------------------------------------------------------------------------------
+```
req1 "elements" => "VM VM storage storage";
@@ -227,17 +227,17 @@ req1 "elements" => " storage storage VM VM";
req1 "elements" => "VM storage VM storage";
-------------------------------------------------------------------------------------------------------------------------
+```
• The number of units per element can be equal to 0. In these cases, the elements parts should not contain the elements
that are not desired. For example, if the user needs the best configuration for three different virtual machines, not
needing any storage nor database, so the elements part should be defined as follows:
-------------------------------------------------------------------------------------------------------------------------
+```
req1 "elements" => "VM VM VM";
-------------------------------------------------------------------------------------------------------------------------
+```
• The elements part of the nonfunctional_requirements is optional. In case the user does not introduce this information,
the IOP consider the basic problem. That is, the finding of the best configuration combining one single unit per element
@@ -249,7 +249,7 @@ Once the IOP conduct its optimization, it returns a complete DOML. This DOML is
as input, with the optimization results introduced. First, the IOP complements the "optimization opt"
part of the DOML adding the found solutions. This is an example:
-------------------------------------------------------------------------------------------------------------------------
+```
optimization opt {
objectives {
"cost" => min
@@ -278,7 +278,7 @@ optimization opt {
decisions ["Storage4_Europe VM_1_CS"]
}
}
-------------------------------------------------------------------------------------------------------------------------
+```
In this example, the IOP returns two different solutions, composed each one of a Virtual Machine and a
Storage element. For each solutions, the value of each objective and the elements chosen are returned.
@@ -286,7 +286,7 @@ Furthermore, the IOP introduces the features of each found solution in the *conc
the DOML. If *concretizations* part is not present in the input DOML, the IOP creates it. This is an
example of returning concretizations.
-------------------------------------------------------------------------------------------------------------------------
+```
concrete_infrastructure con_infra {
provider openstack {
vm concrete_vm {
@@ -325,7 +325,7 @@ concrete_infrastructure con_infra {
}
}
}
-------------------------------------------------------------------------------------------------------------------------
+```
Finally, the last aspect to highlight in this documentation is related to how the IOP ranks the solutions provided as
output. As mentioned, if the problem to solve has two or three different objectives to optimize, the problem converts into
@@ -339,7 +339,7 @@ objectives part of the optimization opt section of the DOML is used, deeming the
Thus, if the user inserts the following objectives as input:
-------------------------------------------------------------------------------------------------------------------------
+```
objectives {
"cost" => min
@@ -347,18 +347,18 @@ objectives {
"performance" => max
}
-------------------------------------------------------------------------------------------------------------------------
+```
All the deployments returned by the IOP will be ranked using the cost as reference, choosing the solution with the less
cost the first one to appear. On the contrary, if the user introduces the following objectives:
-------------------------------------------------------------------------------------------------------------------------
+```
objectives {
"performance" => max
"availability" => max
}
-------------------------------------------------------------------------------------------------------------------------
+```
The performance will be the reference to rank the returned solutions, choosing these solutions with the best performance
as the best ones.
--
GitLab