| Practice Area | Checkpoint | Yes/No | Evidences | How to? |
|---|
| Security | Has the Release Security/Vulnerability table been updated in the protected Security Vulnerabilities wiki space? | NA | Newly discovered issues have already been fixed. So there's no need to update the table. | PTL reviews the NexusIQ scans for their project repos and fills out the vulnerability review table |
| Has the project committed to enabling transport level encryption on all interfaces and the option to turn it off? | Yes | Requirements and test cases for transport layer encryption have been created for all interfaces not currently supporting encryption. |
|
| Has the project documented all open port information? | NA | Holmes is shaded by DCAE hence there's no need for Holmes to maintain the list. If any ports need to be exposed to the external user, we all add them to the list. | Update OOM NodePort List |
| Has the project provided the communication policy to OOM and Integration? | Yes |
| Recommended Protocols |
| Do you have a plan to address by M4 the Critical and High vulnerabilities in the third party libraries used within your project? | Yes |
| - Replace vulnerable packages
- Document false positives in the release notes if it is not possible to replace the vulnerable packages
- Document vulnerabilities inherited in dependencies: include the name of the dependency and any mitigations that can be implemented by an ONAP user
- Ensure by M4 the Nexus-IQ report from “Jenkins CLM” shows 0 critical security vulnerability. Open the Nexus-IQ report for the details on each repository
|
| Architecture
| Has the Project team reviewed the APIs with the Architecture Committee (ARC)? | Yes | | Architecture walk through to understand how each project contributes on Release Use Case. ARC to organize the walk through. |
| Is there a plan to address the findings the API review? | NA | No findings. | The plan could be as simple as a Jira issue to track the implementation of findings or a documented plan within the wiki. |
| Does the team clearly understand that no changes in the API definition is allowed without formal TSC review and approval? | Yes |
| In the case some changes are necessary, bring the request to the TSC for review and approval. |
Is there any changes in the scope, functionalities, deliverable, dependency, resources, API, repositories since M1 milestone? | No | If Yes, please a link to the evidence of these changes. | Critical point to understand is that change is inevitable, and that right timing and clear communication to the community will ease the process of accepting changes. |
| Provide link to the API Documentation. |
| Holmes API Documentation - Dublin |
|
| Release Management | Are committed Sprint Backlog Stories been marked as "Closed" in Jira board? | Yes | https://jira.onap.org/secure/RapidBoard.jspa?rapidView=29&view=planning.nodetail |
|
| Are all tasks associated with Sprint Backlog Stories been marked as "Closed" in Jira? | Yes | The sprint is ongoing and items are still in progress. |
|
| Have all findings from previous milestones been addressed? | NA | No findings. |
|
| Development | Is there any pending commit request older than 36 Business hours in Gerrit? | No |
| Gerrit Query: status:open label:verified -is:draft -label:Code-Review=-1 AND -label:Code-Review=-2 AND is:mergeable age:1week
|
| Has the project team reach the Automated Unit Test Code Coverage expectation? (Refer to artifacts available in Sonar) | Yes | Goal: 55% for Incubation project in the current release | Sonar Guidance on Code Coverage and Static Code Analysis Tools: Sonar |
Are all the Jenkins jobs successfully passed ( Merge-Jobs)? | Yes | https://jenkins.onap.org/view/Merge-Jobs/
| https://jenkins.onap.org/view/Merge-Jobs/ |
| Are all binaries available in Nexus? | Yes | Holmes Nexus Repo
|
|
Integration and Testing
| Have 50% of System Integration Testing Use Cases been implemented successfully in Jenkins? It should include at least 1 CSIT that will be run on Lab-xxx-OOM-Daily Jenkins Job | Yes | CSIT jobs CSIT Use Case Document |
|
| Has the project code successfully passed the Daily Build process? | Yes |
| Goal is to ensure the latest project commit has not broken the Integration Daily Build |
Has the project passed the Integration Sanity Tests? | Yes |
| Integration sanity tests in Dublin Release cover: - ONAP deployment
- All components health check
- VNF onboarding and service creation for vFW use case
- Model distribution for vFW
- vFW instantiation
- vFW closed loop
- vFW deletion
No test failure reported on http://onapci.org/grafana/d/8cGRqBOmz/daily-summary?orgId=1 No Integration Blocking Issue with no workaround: Dublin Release Integration Test Blocking Issues |
| Modeling | Has the Project team provided links to Data Models (e.g, JSON, YANG, Swagger, etc.) for all Shared Information (e.g., APIs, API Payload, Shared Design Model)? | Yes | The data models are described inside the API doc: Holmes API Documentation - Dublin Also, you could find the corresponding Swagger files here: https://gerrit.onap.org/r/gitweb?p=holmes/rule-management.git;a=blob;f=api/swagger.json https://gerrit.onap.org/r/gitweb?p=holmes/engine-management.git;a=blob;f=api/swagger.json | It is a non-blocking item for M3 - The Modeling team is gathering information |