Data Router Platform Maturity for Dublin release.

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	Create performance improvement plan.	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 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. ONAP Platform-level requirements per release 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	Encryption not implemented for: InternalServlet (isAuthorizedForInternal) RouteServlet (isAuthorizedForInternal) PublishServlet StatisticsServlet LogServlet 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 by the project. The project MUST identify the security requirements that the software is intended to meet and an assurance case that justifies why these requirements are met. CII Badging Program Currently DR on Passing level. Data Router (DR) API Guide
Manageability	1	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	Currently implemented: SLF4J (to log events and internal logging) and EELF (for logging API calls) . 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 Please refer to the Logging Enhancements Project documentation for guidance on implementing logging, including the Logging Developer Guide. For transaction tracing, the Logging Spec v1.2 supports MDCs and Markers. In the future, a service mesh could support this. Portal will do the example for other projects. Independent upgrades can be accomplished with OOM and helm charts. Configuration can be externalized into Helm charts via the OOM project. See OOM Configuration Management. See this presentation and follow the Container Image Minimization Guidelines
Usability	1	2	All new API’s must adhere to the ONAP API Common Versioning Strategy and Documentation Guidelines - already in place. All existing APIs must be documented in Swagger 2.0	API versioning already in place. Implementing Semantic Versioning for APIs Utilizes the same semantic versioning methodology that is being used for ONAP’s Release Versioning Strategy; therefore, development teams are familiar with the definition of the methodology. For a given a version number, MAJOR.MINOR.PATCH, increment the: MAJOR position when you make any incompatible API change MINOR position when you add functionality in a backwards-compatible manner PATCH (or BUILD) position when you make invisible (and thus backwards-compatible) bug fixes Details of the specification can be found at http://semver.org/ Update classes with Swagger annotations. Guidance for Implementation This presentation gives a good review of what types of documentation should be done and when in the release lifecycle. Please see the Documentation team for more information.

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
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

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