The intention of this page is to highlight differences between the Platform Maturity requirements for data router Casablanca and Dublin releases.
Area | Target Level for Casablanca Release | Target Level for Dublin Release | Change required. (details below) | Comments |
|---|---|---|---|---|
| Performance | 1 | 2 |
| Performance test results for Casablanca here: Platform maturity: performance/stability test plan. Identify bottlenecks as a start for improvement plan. |
| Security | 1 | 2 | Project level requirements
ONAP Platform-level requirements per release Level 2: 70 % of the projects passing silver
| Encryption not implemented for:
Access control/authorization not implemented. CII Silver badge The project MUST document what the user can and cannot expect in terms of security from the software produced Currently DR on Passing level. |
| Manageability | 1 | 2 |
| Currently implemented:
Considering eelf is one of the suggested logging frameworks for the spec, and we have nothing implemented for slf4j, we should ideally use only eelf for our logging purposes and replace any log4j logging with eelf Guidance for Implementation
|
More information on the levels: Platform Maturity Requirements
Performance
- 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)
Stability
- 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
Resiliency
- Level 0: no redundancy
- Level 1: support manual failure detection & rerouting or recovery within a single site; tested to complete in 30 minutes
- Level 2: support automated failure detection & rerouting
- within a single geographic site
- stateless components: establish baseline measure of failed requests for a component failure within a site
- stateful components: establish baseline of data loss for a component failure within a site
Level 3: support automated failover detection & rerouting
across multiple sites
stateless components
improve on # of failed requests for component failure within a site
establish baseline for failed requests for site failure
stateful components
improve on data loss metrics for component failure within a site
establish baseline for data loss for site failure
Security
Project-level requirements
- Level 0: None
- Level 1: CII Passing badge
- Including no critical and high known vulnerabilities > 60 days old
- Level 2: CII Silver badge, plus:
- All internal/external system communications shall be able to be encrypted.
- All internal/external service calls shall have common role-based access control and authorization using CADI framework.
- Level 3: CII Gold badge
ONAP Platform-level requirements per release
- Level 1: 70 % of the projects passing the level 1
- with the non-passing projects reaching 80% passing level
- Non-passing projects MUST pass specific cryptography criteria outlined by the Security Subcommittee*
- Level 2: 70 % of the projects passing silver
- with non-silver projects:
- completed passing level and 80% towards silver level
- internal/external system communications shall be able to be encrypted
- with non-silver projects:
- Level 3: 70% of the projects passing gold
- with non-gold projects achieving silver level and achieving 80% towards gold level
- Level 4: 100 % passing gold.
Scalability
- 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
Manageability
- 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
Usability
- Level 1:
- User guide created
- Deployment documentation
- API documentation
- Adherence to coding guidelines
- Level 2:
- API Documentation
- All new API’s must adhere to the ONAP API Common Versioning Strategy and Documentation Guidelines
- All existing APIs must be documented in Swagger 2.0
- API Documentation
- Level 3
- Consistent UI across ONAP projects
- Usability testing conducted
- API Documentation
- All new API’s, all external APIs, and all existing API’s that are modified must adhere to the ONAP API Common Versioning Strategy and Documentation Guidelines
- Level 4
- API Documentation
- All API’s for a given project must adhere to the ONAP API Common Versioning Strategy and Documentation Guidelines
- API Documentation