Versions Compared

Key

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

This centralized page, for all Beijing projects, is aimed at identifying the risks as they are foreseen within the release lifecycle.

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

(actions to prevent the risk to materialize)

Contingency Plan - Response Plan

(actions in case the risk materialized)

Probability of occurrence

(probability the risk

materialized)

High-Medium-Low

Impact

High-Medium-Low

Status
1Katel343/12/2018CII Badging - Beijing Release Criteria is addressing Critical Security issues (7-10) but not Severe Security issues (4-6) identified by Nexus IQ Server. Therefore some projects might not pass their CII BadgingAny Project team who has marked 'Unmet' concerning "There MUST be no unpatched vulnerabilities of medium or high severity that have been publicly known for more than 60 days"Fix any remaining Severe security issue post-M4 that will not jeopardize the Integration Testing activities (no major architecture change)Provide an impact analysis about the remaining "Severe" security vulnerabilities and a delivery plan as part of the Casablanca Release.HighMedium
Assessed

In-Process

3/29/18 update:

  • Critical Security under review by Security Subcommittee to determine if further action is required prior Beijing Sign-off
  • Severe Security issues to be planned as part of Casablanca release


2SDC3/12/2018

ONAP DM Modeling SDC Requirements

2 new sets of normative types are required from the Modeling team:

  1. Tosca NFV-based types to replace the current types used in the VOLTE use case.
  2. ETSI SOL-based set of types to support the HPA functionality.

Impact on vVOLTE Use Case

SDC, Integration Team impacted by Modeling project

To be able to meet M4 all this items need to be delivered by 3/16/2018 :

  1. The 2 new sets of normative types be onboarded into SDC.
  2. The CSAR need to be updated and validated in SDC.


If not then VoLTE use case will not be re certified by M4.

Descope this SDC Feature to support DM ModelingHigh

High

Assessed

In-Process

3/29/18 update:

Waiting for the Models to be validated and then the VNF packages should be provided.


3APPC3/13/18

Late delivery of Nitrogen ODL

We were expecting to be integration newer version of ODL in Sprint 2; however, due to late delivery, this work is falling into the last sprint for Beijing release. Nitrogen brings a lot of changes that will make the component unstable until completed and will impact testing, plus may take longer than 1 sprint to complete. In Amsterdam, it took us a couple of sprint to work through issues and there were a number of fixes that were needed in CCSDK discovered as we attempted integration. I expecting that we will have similar experience.

APPC

We are being trying to prioritize the features in APPC and update those that are needed for Beijing as top priority.

Also working closely with CCSDK PTL on any issues found in CCSDK that may block us.

De-scope upgrade to Nitrogen; fall back to released version of Carbon from CCSDK Amsterdam distribution.HighHigh
Assessed

Closed

3/27/18 update:

We are still working through upgrade issues; Nitrogen/Karaf 4 don't seem to be very stable and we are running into issues with bundles freezing up during deployment, which is made difficult to troubleshoot since there are no error messages.

Confidence level to complete by 3/29:  Low

3/29/18 update:

Target completion based on M4 Review: 4/13/2018

4/17/18 update:

APPC upgrade to Nitrogen submitted. Testing of runtime functionality in progress. 


 4 APPC 3/13/18

Late delivery of AAF-91  dependency

This feature was expected by 2/15; however, as of 3/13, delivery of feature has not been received yet. Demo of feature provided did not deliver the requested scope.

 APPC

APPC

SDNC

CLAMP

AAI

Working closely with AAF team to get gap addressed to enable APPC to deliver AAF integration to secure APIs exposed via ODL apidoc.

Based on current discussion with AAF team, we expect this to be a configuration change on APPC only.  If that turns out not to be the case, delivering APPC-404 by code freeze may not be possible.

 De

De-scope APPC-404 in Beijing and address in Casablanca.


Medium at this time; will monitor to see how it goes in the next week and determine if risk level needs to change. High

Closed

3/27/18 update: Still waiting on official delivery of AAF-91 in Nexus. We have tested with beta version provided by Dev team, but APPC feature cannot be completed until AAF-91 is published.

 Medium Assessed

Confidence level to complete by 3/29: Medium to Low

3/29/18 update:

Showstopper for Beijing Release since it has a broader impact than APPC

4/17/18 update:

Integration work is still in progress; currently blocked by AAF-250. AAF team is working on it.

4/25/18 update: Successfully tested AAF integration. APPC-404 complete


5SO

 

Code Merge from ATT Ecomp 1806 to ONAP SO

Risk as identified at M1 and M2 has materialized. ATT code is not merged yet. This may impact code quality (static code checks, security vulnerabilities and Licensing) and code coverage. Code merge may impact other current development. Code Merge is currently planned by March 14.

SO

Working closely for the merge to be on time.


Code merge has been completed on 14th March and around 82K lines of added+ Modified code has been introduced new.

Need to re-asses the functional features commitment.



HighHigh
In Process
Closed.
6VF-C3/12/2018VF-C have planned to implement ETSI NFV compliant API in Beijing, some of the committing companies raised the IPR issue(there may be risks of ETSI intellectual property rights infringement). VF-C also asked about LF suggestions.In order to avoid risks, the LF suggested that VF-C hold contribution until Casablanca or the intermediate version of Beijing and CasablancaVF-C VF-C hold contribution until Casablanca or the intermediate version of Beijing and Casablanca VF-C provide the R1 APIsHighLow
Assessed

Closed.

We consulted Linux Foundation, they said  they are working with ETSI to discuss this and haven’t  have result before M4. They suggested  we wait their conclusion and postpone the implementation to next release to avoid the risk.  So the ETSI interface alignment and implementation will be postponed to Casablanca


7Katel343/16/2018

Security - Support of HTTPS and Certificates Distribution Strategy for the Beijing release is not yet available.  Since all projects need to implement TLS for S3P requirements, a centralized solution is needed so that all projects can have their certificates signed by an ONAP CA and only have to trust the ONAP CA rather than each project distributing self-signed certificates.  Also need a solution for cert subject naming conventions so that systems do not have to disable hostname verification, and have a central DNS solution as well

Any Project team who require a certificate & will support HTTPSFeedback required from the Security SubcommitteeMitigated Action: Re-use openecomp toy CA that was used for a few projects in Amsterdam. Finalize the Certificates/HTTPS strategy by Casablanca M1 (Planning Milestone) since it will potentially require significant development. HighHigh
Assessed

In-Process

3/29/18 update:

Dependency with Risk #4

8OOM

 

Large code drops at the M4 code freeze date does not allow time for OOM to integrate these changes into Beijing. Significant changes are expected from SDC, SO, SDNC/R, and DCAE prior to M4. Any others?All teams

Teams planning to release significant changes to either the docker containers or configuration of these containers should contact the OOM team (Roger Maitland).

ONAP integration will likely start with stable components and proceed with components with significant changes as they are on-boarded to OOM.HighHigh

In-Process

March 28, 2018 Update (M4 code review):

•Priority of cpts to be integrated
1.Message router
2.Dcae
3.Sdnc
4.Multi vim
5.vfc



9OOM/Heat

 

Nexus3 docker image download throttling causing timeouts during onap deploymentsall teamsLF adds more scaling to the AWS based nexus3 serverpull off-hours or from a mirror

Medium

(last occurrence March 19 after 1600 EDT GMT-4)

High (system unstable)

In-Process

3/29/18 update:

IT issue - can you please provide LF Help-desk number?

10VNF Requirements

the
The items in VNF Requirements testability list are not discussed thus some requirement items are not clarified. <This risk needs to be better defined. What is impacted by requirements not discussed? How does this impact the VNF Requirements project?>

VNF Requirements

VNFSDK

Agreement must be reached after a discussing soon. < any clarification/change to requirements can be raised as a JIRA bug to be fixed>Un-clarified items could be removed from R2 or be clarified as bugs during RC0MediumHigh (unclear VNF requirements are published)

In-Process

3/29/18 update:

Can you please provide an update from the meeting organized on 3/22?

11Multi VIM/Cloud


 

MVP
feature has been blocked
features are blocked by -2Multi VIM/Cloud/VFCTeam has
vote to merge the design but need to remove -2Increase coding efforts to expose specific API one by one
voted to make project technical decision makingdefer MVP feature deliver and function support to VoLTEHighHighDone
12 CLAMP 

 Control


Control Loop Design UI needed for CLAMP will be missing CLAMP
 SDC
SDC must be allowed to add the seed code for the DCAE-D part
 manual
manual provisioning of Control Loop blueprint Medium High

Closed

3/29/18 update:

Workaround is available to kick-off the integration testing. DCAE-D remains a stretch goal for Beijing.

4/03/18 update:

closing the risk as there is a workaround

13VNFSDK3/23/18VNFD is not yet finalized, putting HPA support in jeopardy. Related to #2.VNFSDKModel needs to be finalized by 3/26 or HPA updates will be deferred to a maintenance releasedefer to Casablanca or interim releasehighlow

In-Process

3/29/18 update:

Waiting for the Models to be published

14Multi VIM/Cloud


 

OOF integration is under development to enable CSITMulti VIM/Cloud/OOFPrimary functions are under development and lack of CSITdefer to Casablanca or interim releaseMediumHighIn-Process
15 CLAMP 


 UI login authentication using AAF will be missingCLAMP  AAF still facing issue interoperating with CLAMP authentication of user like in R1 release using CLAMP internal DB MediumMedium 

 In-Process

4/02/18 update:

workaround is to use CLAMP internal DB like in R1 ONAP release

16NBI (formerly knows as External API)05/04/2018Late delivery of NBI docker imageAny project team that plan to install this compoentPrioritize a #1 by project team to deliver it by RC1Code is already availableMediumLow

In-Process

17Policy04/10/2018Bad Amsterdam release artifacts, Beijing artifacts unavailableAny project team that integrates with AAF client-cadi jars.Policy will be reverting back to github open source versions of AAF used in Amsterdam release.Policy will not support any AAF Beijing functionality unless supported by older artifactsMediumMediumResolved