...
The minimum viable product that we aim to reach within R2 is to have the CLAMP application Amsterdam (R1) features at least running in the new UI separation model. CLAMP team plans also to increase maturity level to support single site High Availability.
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.
...
Jira Legacy server System Jira columns key,summary,type,created,updated,due,assignee,reporter,priority,status,resolution maximumIssues 2025 jqlQuery project=clamp and issuetype in (story) and fixVersion="Beijing Release" serverId 4733707d-2057-3a0f-ae5e-4fd8aff50176
...
Platform Maturity
Refering to CII Badging Security Program and Platform Maturity Requirements, fill out the table below by indicating the actual level , the targeted level for the current release and the evidences on how you plan to achieve the targeted level.
| Area | Actual level | Targeted level for current release | How, Evidences | Comments | ||||||||||
|---|---|---|---|---|---|---|---|---|---|---|---|---|---|---|
| Performance | 0 | 0 | Run performance basic test, depends on performance criteria availability for level 1 - not able to commit to more than what was done on Amsterdam |
| ||||||||||
| Stability | 0 | 1 (assumption is that 72 hour soak test will be done by Integration team testing); not separate testing will be done at component level | Participate to Stability runs Level 1
|
| ||||||||||
| Resiliency | 1 | 1 |
|
| ||||||||||
| Security | 0 | 1 | Reach CII passing badge, increasing test coverage as remaining item
|
| ||||||||||
| Scalability | 1 | 1 | Level 1 single site horizontal scaling
|
| ||||||||||
| Manageability | 1 | 1 |
| Already using EELF common framework for logging |
| |||||||||||||||||||
| Usability | 1 | 1 | Documentation only for this release - Stretch to have automated API docs (Swagger)
|
|
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 Name | API Description | API Definition Date | API Delivery date | API Definition link (i.e.swagger) |
|---|---|---|---|---|
| To fill outSame as Amsterdam | API exposed by SDC to get list of Alarms and service information's | Date for which the API is reviewed and agreed | To fill outAlready available | Link toward the detailed API description |
| Same as Amsterdam | API exposed by SDC to publish Closed Loop template going to DCAE | Already available | ||
| Same as Amsterdam | API exposed by Policy to create/update policies | Already available | ||
| Same as Amsterdam | API exposed by DCAE to start/stop a Closed Loop | Already available | ||
| Same as Amsterdam | API exposed by DCAE to trigger the deployment/undeployment of a Control Loop template | Already available | ||
| Same as Amsterdam | API exposed by DCAE to get status of a Closed Loop | Already available |
API Outgoing Dependencies
...
| Risk identified | Mitigation Plan | Contingency Plan | Availability of SDC UI/UX SDK | Keep SDC team in the loop to follow up on the SDK | Fall Back to Loose integration or Temporary independent UI|
|---|---|---|---|---|---|
Resources
Link toward the Resources Committed to the Release centralized page.
Release Milestone
...
The project team comply with the ONAP Charter.
Release Key Facts
Fill out and provide a link toward the centralized Release Artifacts.