...
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 | 1 | - To carry out performance tests to get the baseline. This baseline will be used as the start line of our improvement of the component performance.
| - 0 -- none
- 1 – baseline performance criteria identified and measured
- 2 & 3 – performance improvement plans created & implemented
|
| Stability | 0 | 1 | - Perform long-time soaking tests within our team and fix the findings.
- Give the data set to the integration team and ask them to help to carry out a 72 soak test in the integration lab.
| - 0 – none
- 1 – 72 hours component level soak w/random transactions
- 2 – 72 hours platform level soak w/random transactions
- 3 – 6 months track record of reduced defect rate
|
| Resiliency | 1 | 1 | - Holmes is a light-weighted component so the init time is less than 30 mins by nature.
- What we are going to do is to enhance our data persistency a little bit so that after our system is down, we could recover the data along with the recovery of the component itself.
| - 0 – none
- 1 – manual failure and recovery (< 30 minutes)
- 2 – automated detection and recovery (single site)
- 3 – automated detection and recovery (geo redundancy)
|
| Security | 0 | 1 | - Only 2 modules' UT coverage is under 50%, but it's already above 45%. So what we gonna do is to raise the UT coverage of these 2 modules first.
- Change all http interfaces into an https approach.
| - 0 – none
- 1 – CII Passing badge + 50% Test Coverage
- 2 – CII Silver badge; internal communication encrypted; role-based access control and authorization for all calls
- 3 – CII Gold
|
| Scalability | 0 | 1 | - This part of work actually could be partly designed and implementated together with the "Resiliency" requirements because they both have something to do with the data persistency and recovery.
- Beside the data persistency and recovery, we have to design how to solve the load balancing issues.
| - 0 – no ability to scale
- 1 – single site horizontal scaling
- 2 – geographic scaling
- 3 – scaling across multiple ONAP instances
|
| Manageability | 0 | 1 | - Holmes has been using Log4j as its logging tool from the very beginning. What we have to do is to regularize the logging infomation a little bit in order to comply to the requirements from the Logging Enhancements Project.
| - 1 – single logging system across components; instantiation in < 1 hour
- 2 – ability to upgrade a single component; tracing across components; externalized configuration management
|
| Usability | 0 | 1 | - All documents are already. What we are going to do is to keep them updated according to the latest dev status of Holmes.
| - 1 – user guide; deployment documentation; API documentation
- 2 – UI consistency; usability testing; tutorial documentation
|
API Incoming Dependencies
...
