Develop Blueprint Validation User Interface

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.