...
This section is used to document a limitation on a functionality or platform support . We (i.e. limitations that we are currently aware of this limitation and it , and required functionality will be delivered in a future Release.
List identified release gaps (if any), and its impact.). Since the project is in an incubation stage, we are focusing on bringing up the base functionality and then present information on limitations in a proper context.
| Gaps identified | Impact |
|---|---|
| To fill out | To fill out |
...
List the risks identified for this release along with the plan to prevent the risk to occur (mitigation) and the plan of action in the case the risk would materialized (contingency).
Since the project is in an incubation stage, we are focusing on bringing up the base functionality and then present information on risks in a proper context.
| Risk identified | Mitigation Plan | Contingency Plan |
|---|---|---|
| Availability of a global data store that will support resiliency and recovery (job queue). | Use a cloud instance's central database (instead of a global database) to store information required for recovery. It is low risk because we anticipate Music or OOM's kubernetes etcd be available. We need strong consistency (and can tolerate some amount of lag) | Since this will only affect optimization requests that are active/pending, we can ask the callers to resend the request if they receive unexpected error conditions |
| Availability of data to support use cases | Work closely with the use case teams (e.g. vCPE, Scale out), data providers (e.g. A&AI, MultiCloud), and related projects (e.g. SO) to define the requirements more conservatively | Develop the functionality but not activate the functionality of related constraints in the absence of data |
Resources
Fill out the Resources Committed to the Release centralized page.
...