Support Multi-tenancy in ONAPĀ
Requirement:
Jira Legacy |
---|
server | System Jira |
---|
serverId | 4733707d-2057-3a0f-ae5e-4fd8aff50176 |
---|
key | REQ-340 |
---|
|
SO:
Jira Legacy |
---|
server | System Jira |
---|
serverId | 4733707d-2057-3a0f-ae5e-4fd8aff50176 |
---|
key | SO-3029 |
---|
|
...
Jira Legacy |
---|
server | System Jira |
---|
serverId | 4733707d-2057-3a0f-ae5e-4fd8aff50176 |
---|
key | SDC-3188 |
---|
|
CDS:
Jira Legacy |
---|
server | System Jira |
---|
serverId | 4733707d-2057-3a0f-ae5e-4fd8aff50176 |
---|
key | CCSDK-2537 |
---|
|
Policy:
Jira Legacy |
---|
server | System Jira |
---|
serverId | 4733707d-2057-3a0f-ae5e-4fd8aff50176 |
---|
key | POLICY-2717 |
---|
|
Abstract
In order to deal with E2E service orchestration across different network domains, there are ONAP components that need to be logically centralized, such as the Inventory or entry-point of service orchestration or use of common models for services and resources.
...
- If controllers are distributed, Policy executors need to fetch which controller instance to be leveraged for a given resource from A&AIĀ
- Or, we use K8S's namespace/DNS - but this has limitations and would inconsistent with SO's way of dealing with this.
Image Added
SDC
A&AI
An example for A&AI multi-tenancy is the use of owning-entity concept - which defines which group of people owns specific A&AI resources or services.
...