Frankfurt Risks
- cl664y@att.com
- Shankaranarayanan Puzhavakath Narayanan
- bharathb
This centralized page, for all Frankfurt 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 | AAF | 11/6/2019 | AAF continues to have Resource issues for regular AAF work. | No specific Team or component is impacted. | If required, we will request a waiver for JUnit requirements. We will de-activate AAF for Frankfurt release (Security Impact) | High | High | 3/4 - Some Highest/High defects not solved at M4, impacting the Integration team . Working to get additional expertise to reduce the impact on the overall schedule | |
#2 | @David McBride | 11/6/2019 | Description: Projects dependent on oparent are blocked from migrating to Java 11 until oparent v3 is released. Risk: oparent v3 release may happen too late in the Frankfurt release cycle to enable projects to migrate to Java 11 on schedule. | All projects dependent on oparent. | Release oparent v3 ASAP to give projects enough time to complete Java 11 migration within the Frankfurt schedule. | Complete migration in the Guilin release (1H20) | Medium | Low | 3/4 - V3 has been released. Risk will be reviewed on PTL Call (3/9) |
#3 | DCAE | 12/19/2020 | DCAE - MOD delivery (Feature - Self Serve Control Loop) Recent resource change impacts delivery of MOD scope planned under REQ-9 | CLAMP | Prioritizing MOD functional delivery for Frankfurt. CLAMP integration and other non-functional requirement (sonar coverage, https, portal integration) will be deferred to Guilin | Complete MOD delivery for Guilin release and continue SDC-DS for Frankfurt | High | Low | 3/4 - Closed. On target for M4. MOD container release in-progress. Helm chart under review https://gerrit.onap.org/r/#/c/oom/+/102169/. 1/9 - Assessed. CLAMP support through manual workaround for Frankfurt 12/19 - Will be reviewed early Jan and feasibility assessed |
#4 | AAI | 1/9/2020 | Description: AAI UI update to portal 2.6 Risk: Resource contention on AAI means that we might not make the backend software change by M2/M3 | AAI | Asked for resources, Amdocs has committed to provide a resource to look at it over next several weeks but M2/M3 is unlikely | Portal team might have suggestion | High | Low, UI is not heavily used | Resolved - delivered before M4 |
#5 | AAI | 1/9/2020 | Description: Securing Elasticsearch with FOSS Risk: The AAI team does not have a path forward to enable encryption with a component with an acceptable license. Reached out to @Steve Winslow for guidance and his response was that the approaches we had considered are unacceptable. | AAI | Solicit suggestions for alternatives that can be used without license issues | Continue with unencrypted use of Elasticsearch | High | Low | 24 Feb 2020: AAI will continue to use unencrypted communication with elastic |
#6 | SDC | 1/13/2020 | The OVP Testing and Certification Support Within SDC (Frankfurt) feature might not be delivered in R6 | SDC | Asking communi |