Versions Compared

Version Old Version 49 New Version Current
Changes made by

Gildas Lanilis Gmail

Michael O'Brien

Saved on

Key

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

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

...

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

...

CII Badging - Casablanca Release Criteria is about addressing test coverage (including JS)

Therefore some projects might not pass their CII Badging.

...

Find an alternative to the current proposal

https://lists.onap.org/g/Onap-seccom/topic/cii_badging_passing_level/22721721?p=,,,20,0,0,0::recentpostdate%2Fsticky,,,20,2,0,22721721

...

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

...

In-Process

6/27/18 update:

...

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

08/23/18 update: Closed

Agreement to close this risk at M3 review

...

Policy, VID apps that use portal/sdk will be directly impacted under S3P for logging support from portal/sdk due to lack of resources;

...

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


logging in portal/sdk.

In-Process

Aug 09 2018:Michael O'Brien is looking into the portal/sdk and changes needed to performed from logging perspective. So that, the portal/sdk can be consumed by Policy, VID and Portal applications. As long as the logging is integrated in portal/sdk by API freeze, then the risk can be reduced from "High" to "Medium" and when the other teams consume the sdk, then the risk can be closed.
20180726: Log team (Amdocs/AT&T) will work with portal and policy on deployment, spec alignment, aaf security (roles) -

for

Logging Casablanca Scope

Assessed

  • Aug 09 2018: SITHARAMAN T R from IBM stepped up requesting the details on AAF - CADI risk. Once the IBM resources analyze the work and commit for the ETAs on the AAF integration into portal/sdk, then the risk priority can be reduced from High to Medium.
    • Proposal: However, AAF-CADI integration is still a risk to complete in portal-sdk as the work has not yet started by any resources and it will be too late for policy/sdc/vid/aai teams to consume in the same Casablanca release. So the proposal is to target for portal-sdk to integrate in Casablanca depending on the available IBM resources (also depends on their expertise on AAF to pick up the work) and then plan to consume the integrated portal/sdk by other teams in next release (D release).

The following JIRA was created to support SO side:

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
1Katel346/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

https://lists.onap.org/g/Onap-seccom/topic/cii_badging_passing_level/22721721?p=,,,20,0,0,0::recentpostdate%2Fsticky,,,20,2,0,22721721

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

HighLow since agreement on the Mitigation Plan

In-Process

6/27/18 update:

Current proposal presented to the Security Subcommittee to provide awareness

7/25/18 update:

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://lf-onap.atlassian.net/wiki/display/DW/Languages+supported+for+code+coverage

08/23/18 update: Closed

Agreement to close this risk at M3 review

2Portal6/27/2018

Policy, VID apps that use portal/sdk will be directly impacted under S3P for logging support from portal/sdk due to lack of resources;

Policy, VID, Portal

Requesting open community for resources who can help with logging in portal/sdk.

20181005: update Helped with exposing their HTTPS/SSL nodeport under

Jira Legacy
serverSystem Jira
serverId4733707d-2057-3a0f-ae5e-4fd8aff50176
keyOOM-1455

Actively looking for resources to support the logging integration from Portal perspective.HighHigh

Closed

  • Sep 27 2018: The logging work item is moved to Dublin -
    Jira Legacy
    serverSystem Jira
    serverId4733707d-2057-3a0f-ae5e-4fd8aff50176
    keyLOG-534
  • Aug 09 2018:Michael O'Brien is looking into the portal/sdk and changes needed to performed from logging perspective. So that, the portal/sdk can be consumed by Policy, VID and Portal applications. As long as the logging is integrated in portal/sdk by API freeze, then the risk can be reduced from "High" to "Medium" and when the other teams consume the sdk, then the risk can be closed.
  • 20180726: Log team (Amdocs/AT&T) will work with portal and policy on deployment, spec alignment, aaf security (roles) -

Jira Legacy
serverSystem Jira
serverId4733707d-2057-3a0f-ae5e-4fd8aff50176
keyLOG-534

for

Logging Casablanca Scope

3Portal6/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, PortalRequesting 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.HighMedium

Closed

  • Sep 21 2018: The current state is to integrate with AAF not via CADI but via REST as described below in detail. So the Portal team released portal/sdk version 2.4.0 for Casablanca and 2.5.0 along with CADI is deferred for Dublin release.
  • Sep 06 2018: Portal team working with AAF team (Jonathan Gathman) and found few integration issues, however workaround is proposed and is being worked out.

    • Portal team still in the process of integration CADI framework in SDK to talk to AAF. We already have the capability to communicate with AAF for User Role Enforcement via REST.

    • To SDC, Policy, VID teams: We strongly recommend that you start upgrading the current version of SDK to 2.4.0 ( available in staging repository). Our team can help with the upgrade process. Once the CADI integration is fully implemented in 2.5.0 version, at that point it will be easier to just bump your POM to 2.5.0 from 2.4.0 as we are not anticipating any changes in the client code (by design).

      Please note. You are already aware of this but just to confirm:

      1. SDK will be used for User/Role enforcement only as it is doing today (when user accesses the application from browser). For Casablanca, we are not targeting System to System AAF Authorization.
      2. Certificate Management is the responsibility of individual Applications and not SDK.
  • Aug 09 2018: SITHARAMAN T R from IBM stepped up requesting the details on AAF - CADI risk. Once the IBM resources analyze the work and commit for the ETAs on the AAF integration into portal/sdk, then the risk priority can be reduced from High to Medium.
    • Proposal: However, AAF-CADI integration is still a risk to complete in portal-sdk as the work has not yet started by any resources and it will be too late for policy/sdc/vid/aai teams to consume in the same Casablanca release. So the proposal is to target for portal-sdk to integrate in Casablanca depending on the available IBM resources (also depends on their expertise on AAF to pick up the work) and then plan to consume the integrated portal/sdk by other teams in next release (D release).


4Portal6/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, PortalRequesting open community for resources who can help with Actively looking for resources to support the logging integration from Portal perspective.HighHighdeployment 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.MediumMedium

Closed

  • Sep 27 2018: In Dublin release, OOM Team new plan is to address the common DB requirement as part of
    Jira Legacy
    serverSystem Jira
    serverId4733707d-2057-3a0f-ae5e-4fd8aff50176
    keyOOM-1209
  • Sep 06 2018: OOM team (Prateek Khosla) working on
    Jira Legacy
    serverSystem Jira
    serverId4733707d-2057-3a0f-ae5e-4fd8aff50176
    key
LOG-5343Portal6/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, PortalRequesting 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.HighHigh
4Portal6/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, PortalRequesting 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.MediumMedium

In-Process

  • Aug 09 2018: OOM team is looking into the OOM integration related Portal JIRA items, we may expect some support or contribution, but not committed yet. After the commitment the risk can be reduced from High to Medium.
5Policy7/10/2018Scale 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.PolicyIt 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.HighHigh
Jira Legacy
serverSystem Jira
serverId4733707d-2057-3a0f-ae5e-4fd8aff50176
keySO-734

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

  Marking Closed per Gildas request during TSC.

6OOM7/24/2018Helm Chart transfer of ownership to project teams.

Prevents project teams from owning helm charts for their components.

But more importantly, prevents CI/CD.

Need LF to complete work started in Beijing (ticket # 53102) that addresses:

  • trigger builds per project instead of all projects once daily
  • build related Helm charts per project
  • publish Helm artifacts to LF hosted Helm repo

Jira Legacy
serverSystem Jira
serverId4733707d-2057-3a0f-ae5e-4fd8aff50176
keyOOM-752
is blocking
Jira Legacy
serverSystem Jira
serverId4733707d-2057-3a0f-ae5e-4fd8aff50176
keyOOM-1242

Work has now started and meetings are ongoing - will be addressed shortly.

HighHighAssessed7 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.

need to get commitment from SDC/DCAE-DS on development before  8/8, otherwise it will become a stretch goal for Casablanca

CLAMP will fallback on using just the blueprint for C.L distribution from DCAE-DS/SDC  High Medium

Closed

CLAMP will fallback on using just the blueprint for C.L distribution from DCAE-DS/SDC

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

Closed

Pamela Dragosh - The policy team understands and has shared the scope of doing the guard work and is committed to doing the work.

9APPC7/25/2018Decisions 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, SOStick 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-MediumMedium

Closed

1/8: Got confirmation that SO will continue sending the configuration data via the payload, which means this is a test exercise for APPC.

10APPC7/25/2018The 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-MediumLow-Medium

In Progress:

DistrubuteTraffic meeting notes

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

12SO7/19/2018ATT Ecomp 1806 code mergeSOThe 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.HighHigh

Closed

13SO7/24/2018Scale out feature is risky from SO sideSOThe detailed design and the E2E flows are not yet clear and needs to be finalised at the earliest for this feature to go throughThe Usecase may not be able to make it in Casablanca without this clarity being bought.MediumHighclosed14VID8/1/2018Scale out requirements are not finalizedScaling use caseFinalize requirements, or fallback to Beijing implementation of scaling outMeeting today with Scott and Steve (SO)MediumMediumClosed15VID8/1/2018Need for AAF certification to implement HTTPS supportAAF integrationMediumMediumClosed16CLAMP8/10/2018Need Policy API change to support Logging Specification 1.2CLAMP, PolicyTry to get resources for the API changeCLAMP, Policy won't be 100% compliant with the spec, will still try to implement other partsMediumMedium

Closed

this policy api used by CLAMP won't satisfy the log spec given that Policy team doesn't have the resources to implement it.
  • OOM-1164
    to address the a common Mariadb Charts that can be utilized by various applications (in this case Portal).
  • Aug 09 2018: OOM team is looking into the OOM integration related Portal JIRA items, we may expect some support or contribution, but not committed yet. After the commitment the risk can be reduced from High to Medium.
5Policy7/10/2018Scale 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.PolicyIt 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.HighHigh

The following JIRA was created to support SO side:

Jira Legacy
serverSystem Jira
serverId4733707d-2057-3a0f-ae5e-4fd8aff50176
keySO-734

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


  Marking Closed per Gildas request during TSC.

6OOM7/24/2018Helm Chart transfer of ownership to project teams.

Prevents project teams from owning helm charts for their components.

But more importantly, prevents CI/CD.

Need LF to complete work started in Beijing (ticket # 53102) that addresses:

  • trigger builds per project instead of all projects once daily
  • build related Helm charts per project
  • publish Helm artifacts to LF hosted Helm repo

Jira Legacy
serverSystem Jira
serverId4733707d-2057-3a0f-ae5e-4fd8aff50176
keyOOM-752
is blocking
Jira Legacy
serverSystem Jira
serverId4733707d-2057-3a0f-ae5e-4fd8aff50176
keyOOM-1242

Work has now started and meetings are ongoing - will be addressed shortly.


HighHighAssessed7 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.


need to get commitment from SDC/DCAE-DS on development before  8/8, otherwise it will become a stretch goal for Casablanca

CLAMP will fallback on using just the blueprint for C.L distribution from DCAE-DS/SDC  High Medium

Closed

CLAMP will fallback on using just the blueprint for C.L distribution from DCAE-DS/SDC

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

Closed

Pamela Dragosh - The policy team understands and has shared the scope of doing the guard work and is committed to doing the work.


9APPC7/25/2018Decisions 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, SOStick 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-MediumMedium

Closed

1/8: Got confirmation that SO will continue sending the configuration data via the payload, which means this is a test exercise for APPC.

10APPC7/25/2018The 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-MediumLow-Medium

In Progress:

DistrubuteTraffic meeting notes

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

12SO7/19/2018ATT Ecomp 1806 code mergeSOThe 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.HighHigh

Closed

13SO7/24/2018Scale out feature is risky from SO sideSOThe detailed design and the E2E flows are not yet clear and needs to be finalised at the earliest for this feature to go throughThe Usecase may not be able to make it in Casablanca without this clarity being bought.MediumHighclosed14VID8/1/2018Scale out requirements are not finalizedScaling use caseFinalize requirements, or fallback to Beijing implementation of scaling outMeeting today with Scott and Steve (SO)MediumMediumClosed15VID8/1/2018Need for AAF certification to implement HTTPS supportAAF integration

MediumMediumClosed16CLAMP8/10/2018Need Policy API change to support Logging Specification 1.2CLAMP, PolicyTry to get resources for the API changeCLAMP, Policy won't be 100% compliant with the spec, will still try to implement other partsMediumMedium

Closed

this policy api used by CLAMP won't satisfy the log spec given that Policy team doesn't have the resources to implement it.

17Sparky-be9/10/2018Without AAF integration sparky can not launch on Https mode. Which means that portal also must launch in http to let sparky launch in http. This also means that CII requirements wont be meet by sparkySparky-be, AAIPortal should be configured to launch using both http and https. When AAI-UI(sparky) needs to be launched portal should be opened on http mode.



18Policy9/19/2018

HPA Use Case

There were not enough resources given to support the HPA use case. Although Ericsson and AT&T covered the majority of the work, some parts of the development were not finished: CSIT, and S3P.

PolicyUtilize manual creation of policies as was done in Beijing.Request Intel to provide resource to finish the work and drive testing for this.HighLow

19

done

Logging10/02/2018Release multiple 6 jars/1 war in single repo - issues with all or nothing buildlogging only

https://lists.onap.org/g/onap-discuss/topic/release_procedure_for_repos/26675742?p=,,,20,0,0,0::recentpostdate%2Fsticky,,,20,2,0,26675742

This is the first release of logging with actual jar/war artifacts that may need to be in a 1:1 artifact/repo structure instead


work with LF to manually release each artifact by adjusting the pom structure for each artifact

mediummedium (our artifacts jars/war/docker/kubernetes) are for demo only and not used by any team in onap yet

Jira Legacy
serverSystem Jira
serverId4733707d-2057-3a0f-ae5e-4fd8aff50176
keyLOG-715