Overview

Scope

What is this release trying to address?

CLAMP want to enhance the flexibility and ease of introducing new Control loop by:

1. Solve bugs coming during this release

2. implements as much TSC must feature as possible
   
   

Use Cases

The existing use cases are still going to be supported and additional use cases might be supported for the Guilin Release (as defined by the Control loop sub committee and TSC) depending on available resources.

Minimum Viable Product

The minimum viable product that we aim to reach within R7 is to have the CLAMP application Guilin (R7) features at least running with the TSC must being implemented.

Functionalities

List the functionalities that this release is committing to deliver by providing a link to JIRA Epics and Stories. In the JIRA Priority field, specify the priority (either High, Medium, Low). The priority will be used in case de-scoping is required. Don't assign High priority to all functionalities.

Requirements Epics for Guilin, Code mpacting CLAMP

Use Case : None

Functional Requirements : None

18 Non functionals :

10 - TSC MUST HAVE (please indicate where you plan to contribute)

Requirement Epic	TSC Priority	SDC Epic(s) and/or SDC Story(ies)	Committed Contributors

Requirement Epic	TSC Priority	SDC Epic(s) and/or SDC Story(ies)	Committed Contributors
REQ-323 - Each project will update the vulnerable direct dependencies in their code base To Do	RANK #1 - Must Have	key summary type updated assignee priority status Loading... Refresh	Contributors : AT&T
REQ-366 - Containers must crash properly when a failure occurs To Do	RANK #1 - Must Have	key summary type updated assignee priority status Loading... Refresh	Contributors : AT&T
REQ-365 - Containers must have no more than one main process To Do	RANK #1 - Must Have	key summary type updated assignee priority status Loading... Refresh	Contributors : AT&T already DONE in previous release
REQ-380 - ONAP container repository (nexus) must not contain upstream docker images To Do	RANK #1 - Must Have	key summary type updated assignee priority status Loading... Refresh	Contributors : AT&T Align all containers to Database, Java, Python, Docker, Kubernetes, and Image Versions
REQ-379 - ONAP projects must use only approved and verified base images for their containers To Do	RANK #1 - Must Have	key summary type updated assignee priority status Loading... Refresh	Contributors : AT&T Align all containers to Database, Java, Python, Docker, Kubernetes, and Image Versions
REQ-373 - ONAP must complete update of the Python language (from 2.7 -> 3.8) To Do	RANK #1 - Must Have	key summary type updated assignee priority status Loading... Refresh	N/A for CLAMP (CLAMP doesn't use python)
REQ-362 - All containers must run as non-root user To Do	RANK #1 - Must Have	key summary type updated assignee priority status Loading... Refresh	Contributors : AT&T already DONE in previous release
REQ-361 - Continue hardcoded passwords removal To Do	RANK #1 - Must Have	key summary type updated assignee priority status Loading... Refresh	Contributors : AT&T Remove certificates from containers
REQ-349 - Each ONAP project shall define code coverage improvements and achieve at least 55% code coverage To Do	RANK #1 - Must Have		Contributors : All (currently at 73%)
REQ-351 - ONAP must complete update of the java language (from v8 -> v11) To Do	RANK #1 - Must Have		Contributors : AT&T already DONE in previous release

1 - TSC PRIORITY 2 Continuity (please indicate where you plan to contribute)

REQ-358 - No root (superuser) access to database from application container To Do

RANK #2 – Continuity

Contributors : AT&T already DONE in previous release

7- TSC PRIORITY 3 PTL GO/NO GO (please indicate where you plan to contribute)

REQ-340 - ONAP to support Multi - tenancy To Do			Contributors : ?
REQ-374 - ONAP shall use STDOUT for logs collection To Do			Contributors : ?
REQ-369 - Replace nfs share with storage class as a default deployment option To Do			Contributors : ?
REQ-364 - Replace NodePorts with ingress controller as a default deployment option To Do			Contributors : ?
REQ-360 - Application config should be fully prepared before starting the application container To Do			Contributors : ?
REQ-350 - Each ONAP project shall improve its CII Badging score by improving input validation and documenting it in their CII Badging site. To Do			Contributors : ?
REQ-359 - Container rootfs must be mounted readOnly To Do			Contributors : ?

CLAMP Guilin Backlog Overview - Not committed for the release (except for stories and Epics that have been captured in the table in the above sections:"Use Case","Functionals" and "Non-Functionals" ), best effort

Epics (Epics in the table below which doesn't appears in the tables(section Use Case, Functionals and Non functionals) above are not committed for this release !!)

Stories/Tasks (Stories/Tasks in the table below which doesn't appears in the tables(section Use Case, Functionals and Non functionals) above are not committed for this release !!)

Longer term Roadmap

Indicate at a high level the longer term roadmap. This is to put things into the big perspective.

The long term goal is to reach a common platform for managing control loops within ONAP :

CLAMP is a platform for designing and managing control loops.  It is used to setup a control loop, configure it with specific parameters for a particular network service, then deploying and undeploying it.  Once deployed, the user can also update the loop with new parameters during runtime, as well as suspending and restarting it.

It interacts with other systems to deploy and execute the closed loop.  For example, it receives CSAR service package from SDC, associating it with the VF resource.  It requests from DCAE the instantiation of microservices to manage the closed loop flow.  Further, it creates and updates multiple policies in the Policy Engine that define the control loop flow.  

The ONAP CLAMP platform abstracts the details of these systems under the concept of a control loop model.  The setup of a control loop and its management is represented by a workflow in which all relevant system interactions take place.  This is essential for a self-service model of creating and managing control loops, where no low-level user interaction with other components is required.

At a higher level, CLAMP is about supporting and managing the broad operational life cycle of VNFs/VMs and ultimately ONAP components itself. It will offer the ability to configure, test, deploy and update control loop automation - both closed and open. Automating these functions would represent a significant saving on operational costs compared to traditional methods.

Another Key long term goal is to provide a better user experience by having more flexibility to add mico-service without code development.

A Dashboard has been introduced to allow the user to get a quick overview of the status and events  of running control loops.

Release Deliverables

Indicate the outcome (Executable, Source Code, Library, API description, Tool, Documentation, Release Note...) of this release.

Sub-Components

....

Architecture

High level architecture diagram

At that stage within the Release, the team is expected to provide more Architecture details describing how the functional modules are interacting.

Block and sequence diagrams showing relation within the project as well as relation with external components are expected.

Anyone reading this section should have a good understanding of all the interacting modules.

Architecture

• Below we show how the CLAMP application fits into ONAP.  The red figure below shows the CLAMP application components.  There is a design portion and an operations component.

Open

Overall Architecture

Open

CLAMP CORE Technology Architecture

•CLAMP is separated in 3 areas, which are currently (in seed code) both supported by a single application:

1. Design/Setup Time(Cockpit/UI to Configure the received templates)

2.  

   1.  SDC will distribute a CSAR, for a service, the part of the CSAR that CLAMP will use are:

      1.   the Control Loop flow Templates(e.g: blueprint) are defined in DCAE-D(sub-component of SDC) and distributed to CLAMP by SDC. The templates format is TOSCA. The blueprint is also pushed, by SDC, to DCAE platform orchestration engine.

      2. The policy-models defining the DCAE µS used inside the blueprint. note that policy-engine will also receive this SDC distribution and so should be also aware of those policy-models.

   2. policies (configuration and operational policies) are pushed/provisioned towards the Policy Component of ONAP. (those policies will be triggered by DCAE during Closed Loop operations).

      1. The DCAE team needs to provide models to Policy team in order for the Configuration policy to be built. 

   3. DCAE:

      1. design control loop flow (sequences of µS)

      2. expose an API for CLAMP to retrieve the list of existing flow, so that CLAMP can use it to create new Control Loop's instance(also using a DCAE API for this creation)

   4. CDS (starting from Frankfurt release):

      1. expose by an API, the list of actors and corresponding actions, that CLAMP can then configure as part of an Operational policy configuration

3. Run time(DCAE-Policy, grabbing events and triggering policies based actions)

   1. the triggering to deploy(and then effectively start the closed loop)  a blueprint will be manual (via CLAMP cockpit) an automatic deployment based on an event will come in future release.

   2. The CLAMP cockpit will support the following action at runtime:

      1. start (start the provisioned Closed Loop on DCAE)

      2. stop (stop a provisioned Closed loop on DCAE)

4. Dashboard (ELK based)

   1. CLAMP also provides (as a separate components) an ELK stack (with specific configurations for the elk components) that listen to Control Loop events published on DMAAP on specific dmaap topics. 

CLAMP will thus control the typical following control loop flow within ONAP :

Open

Platform Maturity

Please check the centralized wiki page: Guilin Release Platform Maturity

API Incoming Dependencies

List the API this release is expecting from other ONAP component(s) releases.
Prior to Release Planning review, Team Leads must agreed on the date by which the API will be fully defined. The API Delivery date must not be later than the release API Freeze date.

Prior to the delivery date, it is a good practice to organize an API review with the API consumers.

API Outgoing Dependencies

API this release of CLAMP is delivering to other ONAP Component(s) releases.