...
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.
see also Platform Maturity Requirements (S3P).
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:
- 0 -- none
- 1 – baseline performance criteria identified and measured2 & 3 – performance improvement plans created & implementedmeasured (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 | 11 | 2 | Participate to Stability runs Level 1 Jira |
---|
server | ONAP JIRA | columns | key,summary,type,created,updated,due,assignee,reporter,priority,status,resolution |
---|
serverId | 425b2b0a-557c-3c0c-b515-579789cceedb |
---|
key | CLAMP-100276 |
---|
|
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 0 – none1 – 72 hours component level soak w/random transactions2 – 72 hours platform level soak w/random transactions3 – 6 months track record of reduced defect rate |
Resiliency | 1 | 1 (given CLAMP is design time there is no point to adhere to L2 requirement) | Jira |
---|
server | ONAP JIRA |
---|
serverId | 425b2b0a-557c-3c0c-b515-579789cceedb |
---|
key | CLAMP-83 |
---|
|
| - Level 0 – none: no redundancy
- Level 1 – : support manual failure and recovery (< detection & rerouting or recovery within a single site; tested to complete in 30 minutes)
- Level 2 – : support automated detection and recovery (single site)
- 3 – automated detection and recovery (geo redundancy)
| Security | 1 | 1 | - Reach CII passing badge, increasing test coverage as remaining item
- AAF CADI integration
- Infrastructure setup for js test coverage
- 0 – none
- 1 – CII Passing badge + 50% Test Coverage, including no critical and high known vulnerabilities>60 days old
- 2 – CII Silver badge; internal/external communication encrypted; role-based access control and authorization for all calls based on CADI
- 3 – CII Gold
|
Scalability | 1 | 1 | Level 1 single site horizontal scaling Jira |
---|
server | ONAP JIRA |
---|
serverId | 425b2b0a-557c-3c0c-b515-579789cceedb |
---|
key | CLAMP-102 |
---|
|
| - 0 – no ability to scale
- 1 – single site horizontal scaling
- 2 – geographic scaling
- 3 – scaling across multiple ONAP instances
|
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 |
---|
server | ONAP JIRA |
---|
serverId | 425b2b0a-557c-3c0c-b515-579789cceedb |
---|
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 |
UsabilityManageability | 1 | 1 (2, if if CLAMP can get more resource from the community) | - 1 – single logging system across components; instantiation in < 1 hour
2 – ability to upgrade a single component; tracing across components; externalized configuration management ; All application logging to adhere to ONAP Application Logging Specification v1.2 3 - Transaction tracing across components
| 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
- API Documentation
- All API’s for a given project
| 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 | |
API Incoming Dependencies
...
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
...