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 (Deactivated) 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 community for resources | The feature won't be delivered | High | Medium | Descoped from Frankfurt release |
#7 | SDC | 1/13/2020 | Secured connection to Cassandra might not be fully delivered in R6 | SDC | Asking community for resources | Secured connection will be developed in certain areas, while other areas will be left unsecured. Work will be completed in R7 | High | Medium | Phasing approach between Frankfurt and Guilin. Frankfurt part has been delivered |
#8 | MUSIC | 1/14/2020 | MUSIC https support maybe not be fully delivered by Frankfurt release | OOF | Asking community for resources | This will not affect functionality and work will be completed in the next release if we get community resources | High | Medium | Work in progress and we hope to deliver this in Frankfurt. Track under Risk #28 |
#9 | INTEGRATION | 21/12/2019 | Description: WIndriver lab availability after lab move Risk: no resources for developers | Integration | create ONAP stack on Azure | find the budget to deploy new stacks | low | high | De-scoped (move went well) |
#10 | CLAMP | 19/12/2019 | DCAE-MOD CLAMP interaction | CLAMP | prioritizing other functionalities above this one and relying on manual operation to go around DCAE-MOD in case the CLAMP code is ready(depending on priority/resources). | Work will be complete in Giulin release depending on DCAE-MOD and available resources/priorities. | High | Low | Descoped from Frankfurt release |
#11 | SO | 06/01/2020 | AAF integration is blocking the OJSI issues | SO | AAF related changes are not yet merged that is blocking the OJSI issues. | In discussion with security subcomitee. | Med | Med | Working with the security subcomiittee. |
#12 | Policy | 1/21/2020 | Multi Arch work and move to docker hub: Policy asked the work to be finished by M2/M3, which was agreed to in December. But in January we heard very little. Emails went unanswered. We asked for help during the JDK 11 migration for docker images, and got no response. | Policy | Policy will remove commitment from being the test project in Frankfurt. | Jobs will not be merged. | High | Med | 3/4 - will attempt to get this work finished for Frankfurt. May delay image delivery as we need help from LF with sandbox testing of the arm images. https://jira.linuxfoundation.org/servicedesk/customer/portal/2/IT-19098 3/11 - image delivery being delayed due to infrastructure instability. https://jira.linuxfoundation.org/servicedesk/customer/portal/2/IT-19212 3/13 https://jira.linuxfoundation.org/servicedesk/customer/portal/2/IT-19242 3/20 - Policy Committers agreed to remove multi-arch from Frankfurt release. We are reverting the changes so we can produce clean images. There is not enough timely support on this, and it seems the solution is not well-thought out from end-2-end. |
#13 | OOM | 1/21/2020 | Concerns around significant changes required to helm charts has force the decision to delay their transfer to the project teams. During the Frankfurt release helm charts have been in great flux due to new capabilities support being added for Service Mesh, Ingress, Storage Provisioners, k8s 1.16 support and standardized templating. | SO, Portal, SDC, DMaaP, CDS, SDNC, Policy | OOM-1240 will be moved out to next release | Helm chart evolution | High | Low | Planned |
#14 | MultiCloud | 1/21/2020 | MultiCloud Azure plugin is lacking of committed resources, this will result in failing to meet sonar goal as well as potential security vulnerabilities | No specific project or component is impacted by this risk. | Ask for help from community | Asking for waiver to sonar goal as well as security vulnerabilities | High | Low | Requesting waiver or de-scope multicloud-azure module |
#15 | DMaaP | 1/22/2020 | DMaaP components will not be able to remove http ports due to client applications not able to migrate to https in Frankfurt timeframe. | DMaaP, DCAE | http port will be removed in Guilin release once all applications are able to migrate to https | http port will still be exposed | High | Low | Closed - SECCOM clarified only external facing HTTP ports are in scope for Frankfurt. External facing HTTP ports were disabled. |
#16 | PORTAL | 1/22/2020 | Concerns that ONAP components are unable to reach their applications through Portal | Available resources | recommendation to use workaround to use 260 instance | High | High | 1/24 resolution still under review | |
#17 | AAI | 2/13/2020 | AAI will not be able to migrate to Java 11 for Frankfurt | AAI | Stay on Java 8 | Java 8 | High | Low | 24 Feb 2020: AAI will stay on Java 8 in Frankfurt |
#18 | AAI | 2/24/2020 | AAI will probably not meet all security requirements specified in REQ-215: Containers configured per secure recommendationTo Do Staying on jdk-8 our base alpine image will probably not be secured according to outlined specifications - welcome community suggestions for bringing in a better image. Need resources to do non-root user docker images (beyond the fact that the applications run as non-root) and perform extensive regression testing on those images making sure all logging and functionality works on the new containers. | AAI | Community resources brought to the issue | Stay on existing containers | High | Low | Working towards this for RC0 Resolved - the existing method with gosu AAI has used for the last few releases is acceptable even thought the script was showing AAI in exception. |
#19 | SDC | 2/26/2020 | SDC might not deliver a fix to SDC-2721: SDC client works only on httpsClosed, blocking service mesh PoC | OOM | Asking community for resources | Partial service mesh PoC | Medium | Medium | A Stretch goal to RC0, but Service Mesh integration is not part of Frankfurt Release commitment. Service mesh support is deferred to Guilin. |
#20 | DCAE | 2/28/2020 | HTTPS support for new DCAE components requires AAF/cert updates. Due to lack of expertise/support in AAF this work has been stalled (AAF-1081) | DCAE | AAF Team to release new AAF bootstrap image with updates made on Windriver AAF/test instance | HTTPS will be disabled or work-around provided through documentation for manual AAF updates | High | Medium | 03/30/2020 - In-process. Jonathan/AAF team working on releasing new AAF image. DCAE workaround through documentation update being worked in-parellel. |
#21 | Policy | 2/28/2020 | CSIT for legacy Policy/engine failing due to corruption in the CSIT Jenkins Environment. This is blocking the other components from CSIT's running as triggered from Code Review. Lacking SME resources to identify the root cause of the problem which is affecting our ability to deliver other features. Integration team has not been able to provide any help with what the underlying problem is. | Policy | Remove the CSIT for that component to allow other CSIT for components being delivered to Integration to continue use. | Testing will be done in OOM environment for the legacy policy/engine | High | Low | Waiting for Integration to ok removal of CSIT for policy/engine. As the integration team prefers OOM environment to validate testing, the necessity of CSIT for this soon-to-be deprecated component is very small. Mar 2, 2020 Resolved - job removed. |
#22 | SECCOM / OOM / Integration | 3/2/2020 | Security tests have been integrated in CI. For frankfurt priorities have been set by SECCOM, OOM and Integration, the progress seem to be very slow | All | decrease security expectations procedures and examples have been provided to fix some critical issues (e.g. run the pod as root) | High | Medium | @Amy Zwarico, @Sylvain Desbureaux @Krzysztof Opasiak are you OK? I wanted to add a risk line regarding the difficulty to fix security issues.#23 | |
#23 | Integration | 3/2/2020 | Windriver Openlab administration | Integration/use cases | Find a resource for lab admin | a priori no risk for Frankfurt (@Marco Platania with @FREEMAN, BRIAN D support) but such lab admin is very consuming. A solution shall be found for the transition F => G and beyond. In case of troubles, we could even face issue on Frankfurt for the use cases (reinstallation of SB-00 not fully succesful) | medium | High | |
#24 | OOM | 3/15/2020 | hardcoded password removal | a lot (OOM Hardcoded Passwords List) | delaying release to fulfill REQ-235: Password removal from OOM HELM charts Done | Helm chart evolution | High | High | @Krzysztof Opasiakis doing his best but work is HUGE |
#25 | SO | 3/2/2020 | Multi Domain Optical Network requirement couldn't be included in the F release of SO as the code merge wasnt completed. | SO | This requirement would be defered to the next release. | High | High | This has been discussed and agreed upon by XiMiao and agreed upon. | |
#26 | OOF @Vikas Varma | 3/4/2020 |
|
| De-scope CMSO as there are no dependencies on this for Frankfurt release. | High | Medium | Low | |
#27 | EXTAPI | 3/4/2020 | Currently nbi certificates (in org.onap.nbi namespace) are present in the AAF system but cannot be accessed by nbi due to lack of permissons. This is blocking NBI enabling https using AAF certificates. | ExtAPI, AAF | The following bug has been raised for AAF AAF-1104: Wrong permissions when trying to retrieve certificates for NBIClosed, this should then enable ExtAPI to access the certificates via EXTAPI-375: Add support for HTTPS nbi port in OOMClosed | AAF-1104 has now been delivered, so OOM can retrieve Certs. Now NBI working on EXTAPI-415: Configure NBI with http xor https support, using basic spring capabilitiesClosed to update NBI to use these certificates | High | Medium | EXTAPI-375: Add support for HTTPS nbi port in OOMClosed AAF-1104: Wrong permissions when trying to retrieve certificates for NBIClosed EXTAPI-415: Configure NBI with http xor https support, using basic spring capabilitiesClosed |
#28 | MUSIC | 3/12/2020 | MUSIC-572: HTTP port openClosed MUSIC-573: Pods still run as rootClosed Both related to security | None | We are working within ATT to fix this | Security violations will remain | High | Low | MUSIC-573: Pods still run as rootClosed MUSIC-572: HTTP port openClosed Work in progress and we hope to deliver this in Frankfurt. |
#30 | SDC | 3/30/2020 | HTTP endpoints removal | SECCOM | Asking community assistance | HTTP endpoints will remain | High | Medium | Most likely ask for a waiver |