[VAL-14] Develop Blueprint Validation User Interface Created: 02/May/19  Updated: 10/Jun/19  Due: 17/May/19  Resolved: 10/Jun/19

Status: Done
Project: Validation
Component/s: None
Affects Version/s: None
Fix Version/s: None

Type: Improvement Priority: High
Reporter: Deepak Kataria Assignee: Ioakeim Samaras
Resolution: Done Votes: 0
Labels: None
Remaining Estimate: Not Specified
Time Spent: Not Specified
Original Estimate: Not Specified

Attachments: PDF File Akraino_Blueprint_Validation_Mock_Up_Screens_v01.pdf     File BlueprintValidationUI_RESTAPI_R1.yml     File BlueprintValidationUI_RESTAPI_R2.yml    

 Description   

Scope

The blueprint validation user interface (UI) will be hosted by LF servers and will be exposed using public IP and domain names. It will provide a user-friendly way for submitting specific blueprints for validation. Also, it will graphically display the corresponding results. Based on these results, the status of a blueprint can be determined (mature, incubation state, etc.).

In specific, the flowing features will be supported:

  • User authentication, authorization and accounting (AAA) in order to control access to resources, enforce policies on these resources and audit their usage.
  • Ability to define a blueprint for validation using its name, version, layer, desired lab and desired timeslot. This data constitutes a submission. It should be noted that the blueprint family is derived from the blueprint name.
  • Ability to trigger a submission validation. The implementation vehicle for this action is the REST API of Jenkins.
  • Ability to track the lifecycle of a submission. A submission state can be one of the following: submitted, waiting, running and completed. The implementation vehicle for this action is the REST API of Jenkins.
  • When a submission is completed, the corresponding results are retrieved from Nexus repository server. The implementation vehicle for this action is the northbound interface (HTTP) of the aforementioned server. Moreover, a graphic representation of these results will be supported.

 

Prerequisites:

In order for the blueprint validation UI to be functional, the following items are taken for granted:

  • The available timeslots for blueprint validation execution of every lab are defined by the corresponding blueprint owners. It is their responsibility to publish them. Currently, this data is statically stored in the blueprint validation UI postgreSQL database. Apparently, version control is needed. This inconvenience will be handled in the future.
  • The data of an available blueprint for validation (i.e. blueprint name, version, layer, desired lab and desired timeslot) is stored in the postgreSQL database. Apparently, version control is needed. This inconvenience will be handled in the future.
  • The whole installation and deployment of a blueprint and its corresponding blueprint family components (i.e. the appropriate edge cloud stack with its combination of infrastructure hardware components, OS, K8s, software, etc) are already performed in the appropriate lab. Recall that multiple labs can be used for a specific blueprint validation. Also, it is the responsibility of the blueprint submitter to ensure that the edge validation and community CI labs can support comprehensive validation of the blueprint and cover all use case characteristics.

 

 Comments   
Comment by Cristina Pauna [ 10/Jun/19 ]

https://gerrit.akraino.org/r/c/validation/+/735

Comment by Ioakeim Samaras [ 21/May/19 ]

Hi Cristina,

Please find the answers/comments below:

  1. Correct. It is not an efficient approach, so we need to further investigate it. For now, we should use this static data.
  2. The whole installation and deployment of a blueprint and its corresponding blueprint family components (i.e. the appropriate edge cloud stack with its combination of infrastructure hardware components, OS, K8s, software, etc) must have been already performed in the appropriate lab. This is a prerequisite for the blueprint validation UI. Recall that multiple labs can be used for a specific blueprint validation. Also, it is the responsibility of the blueprint submitter to ensure that the edge validation and community CI labs can support comprehensive validation of the blueprint and cover all use case characteristics.
  3. I will send and ask for the resources, when the UI reaches a stable state.

 

Comment by Cristina Pauna [ 21/May/19 ]

Thanks for the replies Ioakeim; here are my follow-ups:

  1. The way I see it, the hw resources in a lab will primarily be used for CI/CD. But the free slots can be made available for "on demand" jobs. From your reply I conclude that the available slots will be handled statically in accordance with input from the lab and blueprint owners.
  2. I agree that this is the responsibility of the Jenkins job. I wanted to make sure that when we talk about testing a certain layer we understand the full dependency that comes from it. For example, triggering the verification for a use-case layer will actually go through:
    • provision OS
    • test OS
    • install k8s
    • test k8s
    • ... deploy and test whatever layer is in between
    • install use-case
    • test use-case
  3. You can send an email to helpdesk@akraino.org
Comment by Ioakeim Samaras [ 21/May/19 ]

Hi,

Please find the answers/comments below:

  1. Currently, the owner of the blueprint must be aware of the required time period of execution and the time availabilities of the appropriate lab in advance. This data is statically stored in the blueprint validation postgreSQL (new container). So, we must apply version control on this data. The owner of the blueprint should be responsible for that. When we will figure out a way of dealing with this inconvenience (for example dynamically retrieve this data), we will modify the code. As you mention, if the hw is still unavailable for the specified time slot, the job will be queued and run during a different time slot. Currently, we have planned to inform the user about this inconvenience, not to deal with it. 
  2. I believe this falls under the responsibility of the Jenkins job. The UI will supply the jenkins with the following data: blueprint, layer, version, lab, flavor (ovs, ovs-dpdk, etc. ) required timeslot. The Jenkins job is responsible for building the complete deployment. If there is another opinion, we need to further discuss.
  3. I agree. The UI and postgreSQL should be hosted by the LF servers. For this purpose, we need subdomains, servers, etc. Can you give me contact details of the person who can provide to us the aforementioned items?
  4. I agree.
Comment by Cristina Pauna [ 20/May/19 ]

I have a few questions and comments on how the UI will work:

   1. Regarding the interaction of UI with Jenkins for the on-demand jobs, normally the jobs are defined in Jenkins and are triggered by timer (run daily, x times a day, etc) or by gerrit change; the duration of a job can be estimated, but it's not always the same. How are we going to determine the "free slot" that we want to schedule our job at? Also, if we schedule it for a certain time, but the hw is unavailable at that time (another job is running) the job we triggered will be queued and may run at a completely different time than the one scheduled.

 2. This UI is supposed to trigger tests, but how is the deploy handled? For example, in order to test the k8s layer we need to have the OS and k8s part installed on the SUT. In order to test an application, we need to have OS+k8s/openstack+the application installed. Is the UI going to trigger that part as well?

3. Where will the UI and database going to be hosted? Normally it should be on the LF servers

4. Viewing the results should be public (no need for account in the UI). Also, I think we need to focus on this part first: the Jenkins run in CI regardless of the UI but we still need an easy way to interpret the results

 

Comment by Ioakeim Samaras [ 09/May/19 ]

Please find attached the proposed REST API model version R2.

BlueprintValidationUI_RESTAPI_R2.yml

Comment by Ioakeim Samaras [ 09/May/19 ]

Please find attached the proposed REST API model version R1.

BlueprintValidationUI_RESTAPI_R1.yml

Generated at Sat Feb 10 06:06:37 UTC 2024 using Jira 9.4.5#940005-sha1:e3094934eac4fd8653cf39da58f39364fb9cc7c1.