This centralized page, for all Casablanca projects, is aimed at identifying the risks as they are foreseen within the release life cycle.
A Risk that materialized becomes an Issue.
Status:
- Identified: a risk that has been identified, but has not yet been analyzed / assessed yet
- Assessed: an identified risk which currently has no risk response plan
- Planned: an identified risk with a risk response plan
- In-Process: a risk where the risk response is being executed
- Closed: a risk that occurred and is transferred to an issue or the risk was solved/avoided
- Not occurred: a risk that was identified but that did not occur
- Rejected: created and kept for tracking purposes but considered not to be used yet
| Risk ID | Project Team or person identifying the risk | Identification Date | Risk (Description and potential impact) | Team or component impacted by the risk | Mitigation Plan (Action to prevent the risk to materialize) | Contingency Plan - Response Plan (Action in case of the risk materialized) | Probability of occurrence (probability of the risk materialized) High/Medium/Low | Impact High/Medium/Low | Status |
|---|---|---|---|---|---|---|---|---|---|
| 1 | Katel34 | 6/27/2018 | CII Badging - Casablanca Release Criteria is about addressing test coverage (including JS) Therefore some projects might not pass their CII Badging. | Any Project team who has JS as part of their code and who will not have enough bandwidth | Find an alternative to the current proposal | If it is confirmed that the solution (https://lists.onap.org/g/Onap-seccom/topic/cii_badging_passing_level/22721721?p=,,,20,0,0,0::recentpostdate%2Fsticky,,,20,2,0,22721721) is the right way to move forward then we believe that we should split the JS test coverage into several phases that will be implemented across multiple ONAP releases depending on each project’s bandwidth: Phase 1 – Setup the infrastructure Phase 2- Analyze the SONAR test coverage and build a plan to meet JS test coverage criteria Phase 3- Add test cases to meet the JS test coverage criteria | High | Low since agreement on the Mitigation Plan | In-Process 6/27/18 update: Current proposal presented to the Security Subcommittee to provide awareness Proposal accepted by the Security Committee. jS test coverage is descoped from the Casablanca release with the assumption that CLAMP will perform a pilot (setup infra, code change and few test cases) as part of the Casablanca release. https://wiki.onap.org/display/DW/Languages+supported+for+code+coverage |
| 2 | Portal | 6/27/2018 | Policy, VID apps that use portal/sdk will be directly impacted under S3P for logging support; also impacted under the JavaScript code coverage support required from portal/sdk due to lack of resources; | Policy, VID, Portal | Requesting open community for resources who can help with logging in portal/sdk. | Actively looking for resources to support the logging integration from Portal perspective. | High | High | Assessed |
| 3 | Portal | 6/27/2018 | Policy, VID, AAI, SDC will be impacted under Security for AAF role management support required from portal/sdk due to lack of resources; | Policy, VID, AAI, SDC, Portal | Requesting open community for resources who can help with AAF role management and CADI integration in portal/sdk. | SDC, Policy, VID teams agreed that they maintain both HTTP and HTTPs ports open, so that the Portal is not completely broken. | High | High | Assessed |
| 4 | Portal | 6/27/2018 | OOM deployment is impacted if the DB scaling changes are not supported by Portal team; also the changes for simplification of etc/hosts entries impacts the OOM deployment which is not committed by Portal team so far due to lack of resources. | OOM, Portal | Requesting open community for resources who can help with deployment upgrades in Portal using OOM. | OOM team is looking into the OOM integration related Portal JIRA items, we may expect some support or contribution, but not committed yet. | Medium | Medium | Assessed |
| 5 | Policy | 7/10/2018 | Scale Out Use Case: Moving to Dmaap based API call to SO for Scale out. This API was for both VID and Policy to use instead of the REST call for simplicity. | Policy | It doesn't look like the SO team has any epic or user story for developing this work in their M1 planning template. | Fallback to using the current RESTful API to make the call - but this may not be sufficient to satisfy the Use Case. | High | High | The following JIRA was created to support SO side: SO-734 - Getting issue details... STATUS Seshu Kumar Mudiganti - I hope you are aware of this work that your AT&T resources are doing. Pamela Dragosh - There is already a story SO-676 created for the Scaleout in Casablanca |
| 6 | OOM | 7/24/2018 | Helm Chart transfer of ownership to project teams. | Prevents project teams from owning helm charts for their components. But more importantly, prevents CI/CD. | High | High | Assessed | ||
| 7 | CLAMP | 7/19/2018 | DCAE-DS service template and policy model not committed for Casablanca | DCAE-DS/SDC, CLAMP | need to agree at least on a design during Casablanca release | CLAMP will fallback on using just the blueprint for C.L distribution from DCAE-DS/SDC | High | Medium | In progress |
| 8 | CLAMP | 7/19/2018 | Policy team not yet sure to support the full api needed for Guard policy | CLAMP, Policy | starting the work using the not final API version given by policy team. guard API is a stretch goal for Casablanca | CLAMP will support scale out using Beijing policy api + new payload to allow injection of SO parameter manually in CLAMP UI. | Medium | Low | Pamela Dragosh - The policy team understands and has shared the scope of doing the guard work and is committed to doing the work. |
| 9 | APPC | 7/25/2018 | Decisions by team on ScaleOut use case for Casablanca is to have SO continue sending the configuration data via the payload, which means this is a test exercise for APPC. If decision is reversed later, then we will need to reassess do-ability based on timeline. | APPC, SO | Stick to original decision to have SO continue sending configuration data in the ScaleOut request payload. | Stick to original decision to have SO continue sending configuration data in the ScaleOut request payload. | Low-Medium | Medium | in progress |
| 10 | APPC | 7/25/2018 | The requirement for new traffic migration LCM API is not finalized | SDNC CCSDK | Agreement with Ajay: Traffic Migration use case will be planning: 1, Pull Ansible with RESTful server docker image from CCSDK/SDNC, 2, APPC sends request to Ansible server with string of playbook name. 3, VNF owner writes all information in playbook. 4, Ansible server sends RESTful request to VNF in order to do the traffic migration use case. Also in R3, APPC with owner of use case will define Traffic Migration LCM API, then implement the Traffic Migration LCM API in R4. | Low-Medium | Low-Medium | in progress | |
| 11 | OOF | 7/25/2018 | Changes to the ONAP Resource Data Model in R3 | OOF | While OOF doesn’t directly interact with SDC, it consumes the model information indirectly through SO/AAI (and passing the solution with some of this information back to SO), and will be impacted if the SO/AAI APIs (and key parts of the payload) change in R3. The chance of occurrence of the risk is low assuming that there will be no/minimal changes to the SO-OOF API and the VNF resource models in AAI when documenting the TOSCA models. | Low | Medium | Closed | |
| 12 | SO | 7/19/2018 | ATT Ecomp 1806 code merge | SO | The code merge of the seed code of ATT 1806 is gettig delayed due to yang model changes. This if further delayed could be an issue for the SO deliverables for Casablanca. | If the code is not merged by July end time frame then we will need to drop the features for casablanca scope. | High | High | In Progress |