This centralized page, for all Guilin projectsHonolulu projects, is aimed at identifying the risks as they are foreseen within the release life cycle.
...
| 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 | OOF |
| Meeting the following requirement for CMSO - Upgrade vulnerable packages | OOF - CMSO | Will be taken up along with the feature implementation if it is required by the use cases | Project team will try to take up activity if no new feature is planned | Low | Low | Identified | ||||||||
| 2 | UUI |
| usecase UI dockers contain GPLv3
| UUI | Will take active action to contact Jira owner and find out witch package contains GPLv3 | Make the current dependencies work well and keep this problem to next release | High | Low | Identified | ||||||||
| 3 | Policy |
| Some package upgrades (e.g., CDS) may require significant rework
| Policy | Will continue to work on upgrades | Obtain a waiver for the problem packages | Medium | Medium | Identified | ||||||||
| 4 | SDC |
| Some package upgrades may require significant rework
| SDC | Will continue to work on upgrades | Obtain a waiver for the problem packages | Medium | Medium | Identified | ||||||||
| 5 | AAI |
| Cannot upgrade to Java 11 for modules dependent on Java 8 only supported Janusgraph
| AAI | Nothing we can really do given the current constraints unless JanusGraph updates to working with Java 11 | Obtain a waiver for the mS with the core tech of Janusgraph | High | Low | Identified | ||||||||
| 6 | DCAE |
|
Due to upstream dependency on NIFI project, some of MOD (NiFI) components (designtool/gen-processor/nifi-registry) will remain in java 8 | DCAE | Migrate/replace MOD NiFI components with custom containers for future release | Request waiver (discused with SECCOM and they are okay with filing exception for NiFI components) | High | Low | Identified | ||||||||
| 7 | DCAE | REQ-437 - COMPLETION OF PYTHON LANGUAGE UPDATE (v2.7 → v3.8 With Cloudify 3.x support releated by Cloudify under 5.1.1, DCAE CM pod upgrade is targetted for H release. This will be major upgrade requiring extensive regression. Marking this risk due to resource/time constraint. | DCAE | Based on severity of issue - we'll assess if new containers can be released for H release or if need to be withheld. | If switching to Guilin version (old CM 4.6 version) - will need waiver for Cloudify container and plugins | Medium | High | Identified | |||||||||
| 8 | CPS |
| Upgrade vulnerable packages, which all are Transient dependencies | CPS | Working with SecCom to resolve high level vulnerabilities | Obtain a waiver for the problem packages | Medium | Low | Identified | ||||||||
