Versions Compared

Key

  • This line was added.
  • This line was removed.
  • Formatting was changed.

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 IDProject Team or person identifying the riskIdentification DateRisk (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
#1AAF11/6/2019AAF 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)


HighHigh3/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
#211/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)MediumLow3/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                                                  

CLAMPPrioritizing MOD functional delivery for Frankfurt. CLAMP integration and other non-functional requirement (sonar coverage, https, portal integration) will be deferred to GuilinComplete MOD delivery for Guilin release and continue SDC-DS for FrankfurtHighLow

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

#4AAI1/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

AAIAsked for resources, Amdocs has committed to provide a resource to look at it over next several weeks but M2/M3 is unlikelyPortal team might have suggestionHighLow, UI is not heavily usedResolved - delivered before M4
#5AAI1/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.  

AAISolicit suggestions for alternatives that can be used without license issuesContinue with unencrypted use of ElasticsearchHighLow24 Feb 2020: AAI will continue to use unencrypted communication with elastic
#6SDC1/13/2020The OVP Testing and Certification Support Within SDC (Frankfurt) feature might not be delivered in R6SDCAsking community for resourcesThe feature won't be deliveredHighMediumDescoped from Frankfurt release
#7SDC1/13/2020Secured connection to Cassandra might not be fully delivered in R6SDCAsking community for resourcesSecured connection will be developed in certain areas, while other areas will be left unsecured. Work will be completed in R7HighMediumPhasing approach between Frankfurt and Guilin. Frankfurt part has been delivered
#8MUSIC1/14/2020MUSIC https support maybe not be fully delivered by Frankfurt releaseOOFAsking community for resourcesThis will not affect functionality and work will be completed in the next release if we get community resourcesHighMediumWork in Progress with IBM helping
#9INTEGRATION21/12/2019

Description: WIndriver lab availability after lab move

Risk: no resources for developers

Integrationcreate ONAP stack on Azurefind the budget to deploy new stackslowhighDe-scoped (move went well)
#10CLAMP19/12/2019DCAE-MOD CLAMP interactionCLAMPprioritizing 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.HighLowDescoped from Frankfurt release
#11SO06/01/2020AAF integration is blocking the OJSI issuesSOAAF related changes are not yet merged that is blocking the OJSI issues.In discussion with security subcomitee.MedMedWorking with the security subcomiittee.
#12Policy1/21/2020

Multi Arch work and move to docker hub:

Migration to DockerHub

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.

PolicyPolicy will remove commitment from being the test project in Frankfurt.Jobs will not be merged.HighMed

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.

#13OOM1/21/2020Concerns 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, PolicyOOM-1240 will be moved out to next releaseHelm chart evolution HighLowPlanned
#14MultiCloud1/21/2020MultiCloud Azure plugin is lacking of committed resources, this will result in failing to meet sonar goal as well as potential security vulnerabilitiesNo specific project or component is impacted by this risk.Ask for help from community Asking for waiver to sonar goal as well as security vulnerabilitiesHighLowRequesting waiver or de-scope multicloud-azure module
#15DMaaP1/22/2020DMaaP components will not be able to remove http ports due to client applications not able to migrate to https in Frankfurt timeframe.DMaaP, DCAEhttp port will be removed in Guilin release once all applications are able to migrate to httpshttp port will still be exposedHighLowClosed - SECCOM clarified only external facing HTTP ports are in scope for Frankfurt. External facing HTTP ports were disabled.
#16PORTAL1/22/2020Concerns that ONAP components are unable to reach their applications through Portal
Available resourcesrecommendation to use workaround to use 260 instanceHighHigh1/24 resolution still under review
#17AAI2/13/2020AAI will not be able to migrate to Java 11 for FrankfurtAAIStay on Java 8Java 8HighLow24 Feb 2020: AAI will stay on Java 8 in Frankfurt
#18AAI2/24/2020

AAI will probably not meet all security requirements specified in

Jira Legacy
serverSystem Jira
columnskey,summary,type,created,updated,due,assignee,reporter,priority,status,resolution
serverId4733707d-2057-3a0f-ae5e-4fd8aff50176
keyREQ-215

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.

AAICommunity resources brought to the issueStay on existing containersHighLow

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.

#19SDC2/26/2020

SDC might not deliver a fix to 

Jira Legacy
serverSystem Jira
serverId4733707d-2057-3a0f-ae5e-4fd8aff50176
keySDC-2721
, blocking service mesh PoC

OOMAsking community for resourcesPartial service mesh PoCMediumMedium

A Stretch goal to RC0, but Service Mesh integration is not part of Frankfurt Release commitment.

Service mesh support is deferred to Guilin.

 #20 DCAE2/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)

DCAEAAF Team to release new AAF bootstrap image with updates made on Windriver AAF/test instanceHTTPS will be disabled or work-around provided through documentation for manual AAF updates  High MediumPlanned
#21Policy2/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/engineHighLow

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.

 Resolved - job removed.

#22SECCOM / OOM / Integration3/2/2020Security tests have been integrated in CI. For frankfurt priorities have been set by SECCOM, OOM and Integration, the progress seem to be very slowAll

decrease security expectations

procedures and examples have been provided to fix some critical issues (e.g. run the pod as root)


HighMedium

Amy Zwarico, Sylvain Desbureaux Krzysztof Opasiak are you OK? I wanted to add a risk line regarding the difficulty to fix security issues.#23

#23Integration3/2/2020Windriver Openlab administrationIntegration/use casesFind 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)

mediumHigh
#24OOM3/15/2020hardcoded password removala lot (OOM Hardcoded Passwords List)

delaying release to fulfill

Jira Legacy
serverSystem Jira
serverId4733707d-2057-3a0f-ae5e-4fd8aff50176
keyREQ-235

Helm chart evolution HighHigh

Krzysztof Opasiakis doing his best but work is HUGE

#25SO3/2/2020Multi Domain Optical Network requirement couldn't be included in the F release of SO as the code merge wasnt completed. SOThis requirement would be defered to the next release.
HighHighThis has been discussed and agreed upon by XiMiao and agreed upon.
#263/4/2020
  • optf/cmso java CLM security violations.
  • docker running as non-root
OOF
  • Still working on getting a resource to resolve this issues.
  • For has working on a resolution as it uses NGINX running on port 80, which needs to run as root.



#27EXTAPI3/4/2020Currently 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 

Jira Legacy
serverSystem Jira
serverId4733707d-2057-3a0f-ae5e-4fd8aff50176
keyAAF-1104
, this should then enable ExtAPI to access the certificates via 
Jira Legacy
serverSystem Jira
serverId4733707d-2057-3a0f-ae5e-4fd8aff50176
keyEXTAPI-375

AAF-1104 has now been delivered, so OOM can retrieve Certs. Now NBI working on 

Jira Legacy
serverSystem Jira
serverId4733707d-2057-3a0f-ae5e-4fd8aff50176
keyEXTAPI-415
 to update NBI to use these certificates

HighMedium

Jira Legacy
serverSystem Jira
serverId4733707d-2057-3a0f-ae5e-4fd8aff50176
keyEXTAPI-375

Jira Legacy
serverSystem Jira
serverId4733707d-2057-3a0f-ae5e-4fd8aff50176
keyAAF-1104

Jira Legacy
serverSystem Jira
serverId4733707d-2057-3a0f-ae5e-4fd8aff50176
keyEXTAPI-415

#28MUSIC3/12/2020

Jira Legacy
serverSystem Jira
serverId4733707d-2057-3a0f-ae5e-4fd8aff50176
keyMUSIC-572

Jira Legacy
serverSystem Jira
serverId4733707d-2057-3a0f-ae5e-4fd8aff50176
keyMUSIC-573

Both related to security

NoneWe are working within ATT to fix thisSecurity violations will remainHighLow

Jira Legacy
serverSystem Jira
serverId4733707d-2057-3a0f-ae5e-4fd8aff50176
keyMUSIC-573

Jira Legacy
serverSystem Jira
serverId4733707d-2057-3a0f-ae5e-4fd8aff50176
keyMUSIC-572

#30SDC3/30/2020HTTP endpoints removalSECCOMAsking community assistanceHTTP endpoints will remainHighMediumMost likely ask for a waiver