...
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 (given CLAMP is design time there is no point to adhere to L2 requirement) | Run performance basic test, depends on performance criteria availability for level 1 - not able to commit to more than what was done on Beijing | - Level 0: no performance testing done
- Level 1: baseline performance criteria identified and measured (such as response time, transaction/message rate, latency, footprint, etc. to be defined on per component)
- Level 2: performance improvement plan created
- Level 3: performance improvement plan implemented for 1 release (improvement measured for equivalent functionality & equivalent hardware)
minimum level for Dublin is 0 except for Control Loop projects.
see Performance levels |
| Stability | 1 | 2 | Participate to Stability runs Level 1 | Jira Legacy |
|---|
| server | System Jira |
|---|
| serverId | 4733707d-2057-3a0f-ae5e-4fd8aff50176 |
|---|
| key | CLAMP-276 |
|---|
|
Integration Team is responsible to run the platform test to prove level 2. | - Level 0: none beyond release requirements
- Level 1: 72 hour component-level soak test (random test transactions with 80% code coverage; steady load)
- Level 2: 72 hour platform-level soak test (random test transactions with 80% code coverage; steady load)
- Level 3: track record over 6 months of reduced defect rate
minimum level for Dublin:2 see Stability levels |
| Resiliency | 1 | 1 (given CLAMP is design time there is no point to adhere to L2 requirement) | | Jira Legacy |
|---|
| server | System Jira |
|---|
| serverId | 4733707d-2057-3a0f-ae5e-4fd8aff50176 |
|---|
| key | CLAMP-83 |
|---|
|
|
Minimum Levels (Dublin)- Runtime Projects: Level 2 (stretch goal Level 3)
- NOTE: For Dublin, the building blocks will be put in place for Level 3 geo-redundancy, and a few projects will pilot it
- All other Projects: Level 1 (stretch goal Level 2)
see Resiliency Levels |
| Security | 1 | 1 | same as in Casablanca, not enough resource to allocate to this effort.
| see Security Levels |
| Scalability | 1 | 1 | Level 1 single site horizontal scaling | Jira Legacy |
|---|
| server | System Jira |
|---|
| serverId | 4733707d-2057-3a0f-ae5e-4fd8aff50176 |
|---|
| key | CLAMP-102 |
|---|
|
| - Level 0: no ability to scale
- Level 1: supports single site horizontal scale out and scale in, independent of other components
- Level 2: supports geographic scaling, independent of other components
- Level 3: support scaling (interoperability) across multiple ONAP instances
Minimum Levels (Dublin) - Runtime Projects: Level 1
- NOTE: For Dublin, the building blocks will be put in place for Level 2 geographic scaling, and a few projects will pilot it
- All other Projects: Level 0
see Scalability levels |
| Manageability | 1 | 1 (2, if CLAMP can get more resource from the community) |
| - Level 1:
- All ONAP components will use a single logging system.
- Instantiation of a simple ONAP system should be accomplished in <1 hour with a minimal footprint
- Level 2:
- A component can be independently upgraded without impacting operation interacting components
- Component configuration to be externalized in a common fashion across ONAP projects
- All application logging to adhere to ONAP Application Logging Specification v1.2
- Implement guidelines for a minimal container footprint
- Level 3
- Transaction tracing across components
Minimum Levels (Dublin)- All Projects: Level 2
- New projects should adhere to v1.2
- Existing projects have stretch goal for v1.2
- Stretch Goal: Level 3
- Note: some work will be done in Dublin to test/prep for a release upgrade strategy
see Manageability Levels |
| Usability | 1 | 1 (2, if CLAMP can get more resource from the community) | CLAMP is not anticipating new API at this point, so we are technically compliant with API CVS at this point | Level 1: - User guide created
- Deployment documentation
- API documentation
- Adherence to coding guidelines
- Level 2:
- Level 3
- Consistent UI across ONAP projects
- Usability testing conducted
- API Documentation
- Level 4
Minimum Levels (Dublin)- All Projects: Level 2
- Stretch Goal: External APIs also follow the Versioning Strategy
- see Usability Levels
|
...
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.
...
| Risk identified | Mitigation Plan | Contingency Plan |
|---|
| new policy api(and contents) for CRUD operations on policies not defined yet | use old policy API | create config. policy the old("R3 release") way |
| blueprint generated by DCAE-D (SDC) might not be compatible with DCAE | keep current manual blueprint onboarding in SDC (as VFI). | manually created blueprint with correct format manually on boarded in SDC and distributed to CLAMP and DCAE. |
| new DCAE API to get status of µS not yet defined | | use current DCAE api | monitor only µS created by CLAMP |
Resources
Link toward the Resources Committed to the Release centralized page.
Release Milestone
...
Each project must edit its project table available at Project FOSS
Charter Compliance
The project team comply with the ONAP Charter.
Release Key Facts
Fill out and provide a link toward the centralized Release Artifacts.