- An appropriate mariadb instance is up and running (look at the Database subsection).
This prerequisite concerns both of the UI modes.
-- The available labs for blueprint validation execution are defined by the corresponding lab owners (look at the Database subsection). It is their responsibility to publish them. Currently, this data is statically stored in the blueprint validation UI mariadb database. In order for a lab owner to update them, he/her must update the corresponding table entries. This inconvenience will be handled in the future.
- This prerequisite concerns only the full control loop mode.
-
-- The available timeslots for blueprint validation execution of every lab are defined by the corresponding lab owners (look at the Database subsection). It is their responsibility to publish them. Currently, this data is statically stored in the blueprint validation UI mariadb database. In order for a lab owner to update them, he/her must update the corresponding table entries. This inconvenience will be handled in the future.
- This prerequisite concerns only the full control loop mode.
+- The available labs and their silos (i.e. which silo is used by a lab in order to store results in Nexus) for blueprint validation execution are stored in mariadb (look at the Database subsection). It is the lab owner's responsibility to update them using the UI.
+ This prerequisite concerns both the partial and the full control loop modes.
-- The data of the lab silos (i.e. which silo is used by a lab in order to store results in Nexus) is stored in the mariadb database (look at the Database subsection). It is the blueprint owner's responsibility to publish it. Currently, this data is statically stored in the blueprint validation UI mariadb database. In order for a blueprint owner to update it, he/her must update the corresponding table entries. This inconvenience will be handled in the future.
+- The available timeslots for blueprint validation execution of every lab are stored in the mariadb (look at the Database subsection). It is the lab owner's responsibility to update them using the UI.
This prerequisite concerns only the full control loop mode.
-- The data of available blueprints (i.e. blueprint name) is stored in the mariadb database (look at the Database subsection). It is the blueprint owner's responsibility to publish it. Currently, this data is statically stored in the blueprint validation UI mariadb database. In order for a blueprint owner to update it, he/her must update the corresponding table entries. This inconvenience will be handled in the future.
+- The data of available blueprints (i.e. blueprint name) is stored in the mariadb database (look at the Database subsection). This data is automatically updated by the UI using info from Nexus. If a blueprint owner's is not satisfied with this info, he/her must update it using the UI.
This prerequisite concerns only the full control loop mode.
-- The data of an available blueprint instance for validation (i.e. version, layer and description of the layer) is stored in the mariadb database (look at the Database subsection). It is the blueprint owner's responsibility to publish it. Currently, this data is statically stored in the blueprint validation UI mariadb database. In order for a blueprint owner to update it, he/her must update the corresponding table entries. This inconvenience will be handled in the future.
+- The data of an available blueprint instance for validation (i.e. version and layer) is stored in the mariadb database (look at the Database subsection). This data is automatically updated by the UI using info from Nexus. If a blueprint owner's is not satisfied with this info, he/her must update it using the UI.
This prerequisite concerns only the full control loop mode.
- A Jenkins instance exists capable of executing blueprint validation tests on the specified lab and storing the results to Nexus server (look at the Jenkins configuration subsection).
- This prerequisite concerns only the full control loop mode.
+ Also, this data is updated using info from results fetched from Nexus. This prerequisite concerns only the full control loop mode.
- A Nexus server exists where all the blueprint validation results are stored (look at the Nexus subsection).
This prerequisite concerns both of the UI modes.
./deploy.sh TAG_PRE=dev-mariadb MARIADB_ROOT_PASSWORD=<root user password> MARIADB_AKRAINO_PASSWORD=<mariadb akraino user password> UI_ADMIN_PASSWORD=<UI admin user password> UI_AKRAINO_PASSWORD=<UI akraino user password>
mysql -p<MARIADB_AKRAINO_PASSWORD> -uakraino -h <IP of the mariadb container> < ../../ui/db-scripts/examples/initialize_db_example.sql
-In the context of the full control loop mode, the following tables must be initialized with appropriate data:
+In the context of the UI application, the following tables exist in the database:
+
+- lab (here, every lab owner should store the name of the lab and the silo used for storing results in Nexus)
+- timeslot (here, every lab owner should register the available timeslots that can be used for blueprint validation test execution)
+- blueprint_layer (here, all the blueprint layers should be registered. These layers will be referenced by the blueprint instances)
+- blueprint (here, every blueprint owner should register the name of the blueprint)
+- blueprint_instance_for_validation (here, every blueprint owner should register the blueprint instances for validation, i.e. version and layer)
+- blueprint_instance_blueprint_layer (here, the many-to-many relationship between blueprint instances and layers is formulated)
+- blueprint_instance_timeslot (here, the many-to-many relationship between blueprint instances and timeslots is formulated)
-- lab (here every lab owner should store the name of the lab)
-- timeslot (here every lab owner should register the available timeslots that can be used for blueprint validation test execution)
-- silo (here every lab owner should register the silo which is used for storing results in Nexus, for example for AT&T lab the value is 'att-blu-val')
-- blueprint (here every blueprint owner should register the name of the blueprint)
-- blueprint_instance_for_validation (here every blueprint owner should register the blueprint instances for validation, i.e. version, layer and description of a layer)
+As it has been already mentioned, a user can perform CRUD operations on these tables using the UI. Also, all these tables except from lab and timeslot are initialized and updated automatically
+by the UI by fetching data from Nexus. It is the lab owners responsibility to update them if a modifications is needed (especially the data related to lab and timeslot tables).
-The following file can be used for initializing the aforementioned data (as it was performed in the above example using the 'mysql -p<MARIADB_AKRAINO_PASSWORD> -uakraino -h <IP of the mariadb container> < ../../ui/db-scripts/examples/initialize_db_example.sql' command):
+An example of data initialization is stored in the following file:
db-scripts/examples/initialize_db_example.sql
-Some of this data is illustrated below (refer to 'org.akraino.validation.ui.data' package for more info regarding available values):
+That is the reason why the command 'mysql -p<MARIADB_AKRAINO_PASSWORD> -uakraino -h <IP of the mariadb container> < ../../ui/db-scripts/examples/initialize_db_example.sql' has been used previously.
+
+Some of this data is illustrated below:
.. code-block:: console
- Lab
- id:1, lab:0 (0 stands for AT&T)
+ Labs:
+ id:1, lab:'att', silo:'att-blu-val'
Timeslots:
id:1 , start date and time: 'now', duration: null, lab: 1
- Silo
- id:1, silo: 'att-blu-val', lab: 1
+ Blueprint layers:
+ id:1, layer: 'hardware';
Blueprints:
- id: 3 , name : 'REC'
+ id: 2 , blueprint_name : 'rec'
Blueprint Instances:
- id: 2, blueprint_id: 3 (i.e. REC), version: "latest", layer: 0 (i.e. Hardware), layer_description: "AT&T Hardware"
+ id: 2, blueprint_id: 2 (i.e. rec), version: "master"
+
+ blueprint_instances_blueprint_layers
+ blueprint_id: 2 (i.e. rec), layer_id: 1 (i.e. hardware)
+
+ blueprint_instances_timeslots
+ blueprint_instance_id: 2 (i.e. rec), timeslot_id: 1 (i.e. now in att lab)
It should be noted that currently the start date and time and the duration of the timeslot are not taken into account by the UI (see limitation section). Therefore, a user should define 'now' and null respectively for their content.
Based on this data, the UI enables the user to select an appropriate blueprint instance for validation.
-Currently, this data cannot be retrieved dynamically by the UI (see limitations subsection). For this reason, in cases of new data, a user should define new entries in this database.
+In the following lines it is explained how a user can update database using the mysql tool. However, it is advised that UI should be used for this purpose as it supports a more user-friendly way.
For example, if a user wants to define a new lab with the following data:
- lab: Community
+ lab: community, silo : 'community'
the following file should be created:
content:
SET FOREIGN_KEY_CHECKS=1;
use akraino;
- insert into lab values(2, 2);
-
-2 stands for community lab. Refer to 'org.akraino.validation.ui.data' package for more info.
+ insert into lab (id, lab, silo) values(2, 'community', 'community');
Then, the following command should be executed:
content:
SET FOREIGN_KEY_CHECKS=1;
use akraino;
- insert into timeslot values(2, 'now', null, 1);
-
-1 is the id of the AT&T lab.
-
-Then, the following command should be executed:
-
-.. code-block:: console
-
- mysql -p<MARIADB_AKRAINO_PASSWORD> -uakraino -h <IP of the mariadb container> < ./dbscript.sql
-
-For example, if a user wants to define a new silo with the following data:
-
- silo: 'community-blu-val', lab: AT&T
-
-the following file should be created:
-
-name: dbscript
-content:
- SET FOREIGN_KEY_CHECKS=1;
- use akraino;
- insert into silo values(2, 'community-blu-val', 2);
+ insert into timeslot values(2, 'now', null, 2);
2 is the id of the community lab.
mysql -p<MARIADB_AKRAINO_PASSWORD> -uakraino -h <IP of the mariadb container> < ./dbscript.sql
-Furthermore, if a user wants to define a new blueprint, namely "newBlueprint" and a new instance of this blueprint with the following data:
-
- version: "latest", layer: 2 (i.e. K8s), layer_description: "K8s with High Availability Ingress controller"
-
-the following file should be created:
+Furthermore, if a user wants to define a new blueprint, namely "newBlueprint", and an instance of this blueprint with version "master" and layer "k8s" and assign a timeslot to it, the following file should be created:
name: dbscript
content:
SET FOREIGN_KEY_CHECKS=1;
use akraino;
- insert into blueprint (blueprint_id, blueprint_name) values(4, 'newBlueprint');
- insert into blueprint_instance (blueprint_instance_id, blueprint_id, version, layer, layer_description) values(6, 4, 'latest', 2, 'K8s with High Availability Ingress controller');
+ insert into blueprint (id, blueprint_name) values(3, 'newBlueprint');
+ insert into blueprint_instance (id, blueprint_id, version) values(3, 3, 'master');
+ insert into blueprint_layer (id, layer) values(4, 'k8s');
+ insert into blueprint_instance_blueprint_layer (blueprint_instance_id, blueprint_layer_id) values(3, 4);
+ insert into blueprint_instance_timeslot (blueprint_instance_id, timeslot_id) values(3, 2);
Then, the following command should be executed:
Furthermore, this instance must have the following option enabled: "Manage Jenkins -> Configure Global Security -> Prevent Cross Site Request Forgery exploits".
-Also, currently, the corresponding Jenkins job should accept the following as input parameters: "SUBMISSION_ID", "BLUEPRINT", "VERSION", "LAYER", "LAB" and "UI_IP".
+Also, currently, the corresponding Jenkins job should accept the following as input parameters: "SUBMISSION_ID", "BLUEPRINT", "VERSION", "LAYER", "OPTIONAL", "LAB" and "UI_IP".
The "SUBMISSION_ID" and "UI_IP" parameters (i.e. IP address of the UI host machine-this is needed by the Jenkins instance in order to send back Job completion notification) are created and provided by the back-end part of the UI.
-The "BLUEPRINT", "VERSION", "LAYER" and "LAB" parameters are configured by the UI user.
+The "BLUEPRINT", "VERSION", "LAYER" and "LAB" parameters are configured by the UI user. The parameter "OPTIONAL" defines whether the optional test cases should be included or not.
Moreover, as the Jenkins notification plugin (https://wiki.jenkins.io/display/JENKINS/Notification+Plugin) seems to ignore proxy settings, the corresponding Jenkins job must be configured to execute the following commands at the end (Post-build Actions)
These results must be available in the following url:
- https://nexus.akraino.org/content/sites/logs/<lab_silo>/<Blueprint name>/<Blueprint version>/<timestamp>/results/<layer>/<name_of_the_test_suite>
+ https://nexus.akraino.org/content/sites/logs/<lab_silo>/bluval_results/<Blueprint name>/<Blueprint version>/<timestamp>/results/<layer>/<name_of_the_test_suite>
where <lab_silo> is the silo used by a lab for storing results in Nexus (for example 'att-blu-val'), <Blueprint name> is the name of the blueprint, <Blueprint version> the the blueprint version, <timestamp> is the timestamp used for producinf the results, <layer> is the blueprint layer and <name_of_the_test_suite> is the name of the corresponding test suite.
Below, an example URL is illustrated
- https://nexus.akraino.org/content/sites/logs/att-blu-val/rec/master/20190611-132818/results/hardware/bios_version/
+ https://nexus.akraino.org/content/sites/logs/att-blu-val/bluval_results/rec/master/20190611-132818/results/hardware/bios_version/
-Moreover, the results should be stored in the 'output.xml' file and placed in the aforementioned URL using the following format:
-
-TBD
+Moreover, the results should be stored in the 'output.xml' file and placed in the aforementioned URL.
Compiling
~~~~~~~~~
Deploying
~~~~~~~~~
-The pom.xml file supports the building of an appropriate container image using the produced war file. Also, a script has been developed, namely validation/docker/ui/deploy.sh which easily deploys the container.
+The pom.xml file supports the building of an appropriate container image using the produced war file.
-This script accepts the following as input parameters:
+In order to build the image, the following commands should be executed:
+
+.. code-block:: console
+
+ cd validation/ui
+ mvn docker:build -Ddocker.filter=akraino/validation:dev-ui-latest
+
+Also, a script has been developed, namely validation/docker/ui/deploy.sh which easily deploys the container. This script accepts the following as input parameters:
CONTAINER_NAME, the name of the contaner, default value is akraino-validation-ui
DB_IP_PORT, the IP and port of the maridb instance, this variable is required
NAME, the name of the mariadb image, default value is validation
TAG_PRE, the first part of the image version, default value is ui
TAG_VER, the last part of the image version, default value is latest
-JENKINS_URL, the URL of the Jenkins instance (http or https must be defined), this variable is required
-JENKINS_USERNAME, the Jenkins user name, this variable is required
-JENKINS_USER_PASSWORD, the Jenkins user password, this variable is required
-JENKINS_JOB_NAME, the name of Jenkins job capable of executing the blueprint validation tests, this variable is required
+JENKINS_URL, the URL of the Jenkins instance (http or https must be defined), the default value is 'https://jenkins.akraino.org/'
+JENKINS_USERNAME, the Jenkins user name, the default value is 'demo' (in the context of UI full control loop mode, this parameter must be changed to include a real Jenkins user)
+JENKINS_USER_PASSWORD, the Jenkins user password, the default value is 'demo' (in the context of UI full control loop mode, this parameter must be changed to include a real Jenkins user password)
+JENKINS_JOB_NAME, the name of Jenkins job capable of executing the blueprint validation tests, the default value is 'validation' (in the context of UI full control loop mode, this parameter must be changed to include a real Jenkins job name)
NEXUS_PROXY, the needed proxy in order for the Nexus server to be reachable, default value is none
JENKINS_PROXY, the needed proxy in order for the Jenkins server to be reachable, default value is none
+CERTDIR, the directory where the SSL certificates can be found, default value is the working directory where self signed certificates exist only for demo purposes
-In order to build the image using only the required parameters, the following data is needed:
+So, for a functional UI, the following prerequisites are needed:
-- The mariadb akraino user password (look at the Database subsection)
-- The IP and port of the mariadb
-- The Jenkins url
-- The Jenkins username and password
-- The name of Jenkins Job
+- The mariadb container in up and running state
+- A Jenkins instance capable of running the blueprint validation test (this is optional and is needed only for UI full control loop mode)
+- A Nexus repo in which all the test results are stored.
-Then, the following commands can be executed in order to build and deploy the UI container:
+Then, the following commands can be executed in order to deploy the UI container:
.. code-block:: console
-
- cd validation/ui
- mvn docker:build -Ddocker.filter=akraino/validation:dev-ui-latest
cd ../docker/ui
- ./deploy.sh TAG_PRE=dev-ui DB_IP_PORT=<IP and port of the mariadb> MARIADB_AKRAINO_PASSWORD=<mariadb akraino password> JENKINS_URL=<http://jenkinsIP:port> JENKINS_USERNAME=<Jenkins user> JENKINS_USER_PASSWORD=<Jenkins password> JENKINS_JOB_NAME=<Jenkins job name>
+ ./deploy.sh TAG_PRE=dev-ui DB_IP_PORT=<IP and port of the mariadb> MARIADB_AKRAINO_PASSWORD=<mariadb akraino password>
The content of the DB_IP_PORT can be for example '172.17.0.3:3306'.
The UI should be available in the following url:
- http://localhost:8080/bluvalui/
+ https://localhost:8443/bluvalui/
+
+Note that the deployment uses the network host mode, so the ports 8080 and 8443 must be available on the host.
-Note that the deployment uses the network host mode, so the 8080 must be available on the host.
+As far as the SSL certificates are concerned, self-signed built-in certificates exist in the 'validation/docker/ui' directory which are used by default. It should be noted that these
+certificates should be used only for demo purposes. If a user wants to use different ones which are more appropriate for a production environment, the directory that contains these new
+certificates must be defined using the 'CERTDIR' parameter of the 'validation/docker/ui/deploy.sh' script. It should be noted that the certificates must have specific names, that are 'bluval.crt'
+and 'bluval.key' for the certificate and the key respectively.
User's guide
-----------------
-----------
- The UI has been tested using Chrome and Firefox browsers.
- The back-end part of the UI does not take into account the start date and time and duration of the configured timeslot. It immediately triggers the corresponding Jenkins Job.
-- Results data manipulation (filtering, graphical representation, indexing in time order, etc) is not supported.
-- The silos, labs, and the available blueprints and timeslots must be manually configured in the mariadb database.
\ No newline at end of file
Code Review / validation.git / blobdiff