Table of Contents
...
User Story | Affected Component | Description | JIRA | Priority | ||||||||
---|---|---|---|---|---|---|---|---|---|---|---|---|
SO shall get the ASD-based CNF package from SDC and store its metadata to SO Catalog DB | SDC Controller, CatalogDB Adapter, CatalogDB | SO shall get the ASD-based CNF package (SDC Service CSAR) from SDC and store its metadata to SO Catalog DB. Pre Condition:
Post Condition:
|
| 1 | ||||||||
| 1 | |||||||||||
| 1 | |||||||||||
For ASD-based CNF provisioning, SO shall process model info and decide flows | API Handler, RequestDB Adapter, RequestDB, SO BPMN Infra, AAI | SO shall process ASD model info and decide ASD provisioning flows Pre Condition:
Post Condition:
|
| 2 | ||||||||
Task:
| 2.1 | |||||||||||
Task:
| 2.2 | |||||||||||
Task:
| 2.3 | |||||||||||
Task:
| 2.4 | |||||||||||
Task:
| 2.5 | |||||||||||
SO CNFM shall process ASD-based CNF Lifecycle orchestration | SO CNFM, ASD Repository, Helm Artifact Repository, OOF, AAI, SDNC Adapter, SDNC, CDS, CNF Adapter | SO CNFM shall process ASD-based CNF Lifecycle orchestration Pre Condition:
Post Condition:
Note: PoC, ASD external CPDs will not be handled (TBD) Note: ASD Repository, Helm Artifact Repository, Image Artifact Repository will be handled by another Epic, which is defined in Application Package Distribution |
| 3 | ||||||||
Task: Create SO CNFM and make it available in ONAP
| 3.1 | |||||||||||
Create SO CNFM REST API swagger, based on the ASD LCM Restful API, ASD LCM RESTful Protocols for SO CNF Manager and Swagger file (ASD LCM RESTful Protocols for SO CNF Manager) | 3.2 | |||||||||||
Task: Support for SO CNFM NBI API Handler
| 3.3 | |||||||||||
Task:
| 3.4 | |||||||||||
Task:
| 3.5 | |||||||||||
Task:
| 3.6 | |||||||||||
Task:
| 3.7 | |||||||||||
Task: Create SO CNFM Instance Database Management
| 3.8 | |||||||||||
Task:
| 3.9 | |||||||||||
Task:
| 3.10 | |||||||||||
Task:
| 3.11 | |||||||||||
Task:
| 3.12 | |||||||||||
Task:
| 3.13 | |||||||||||
Task:
| 3.14 | |||||||||||
SO Client shall send the A La Carte Request for ASD-based CNF orchestration (note: E2E support is out of PoC scope) | SO Client, SO, SO BPMN, CNFM CNF Adapter | SO Client shall send the A La Carte Request for ASD-based CNF orchestration Pre Condition:
Post Condition:
|
| 4 | ||||||||
Task:
| 4.1 | |||||||||||
Task:
| 4.2? |
...
Option A: use Helm Command:
Option B: use of CNF Adapter (this is not part of initial PoC)
Note: use of CDS is TBD.
Tenant Support
The Tenant support will be realized by Kubernetes cluster, namespace, node and container. Initially, namespace can be used to restrict API access, to constrain resource usage and to restrict what containers are allowed to do.
Assumption & Requirements (from cloud.google.com)
source: https://cloud.google.com/kubernetes-engine/docs/best-practices/enterprise-multitenancy
The best practices in this guide are based on a multi-tenant use case for an enterprise environment, which has the following assumptions and requirements:
- The organization is a single company that has many tenants (two or more application/service teams) that use Kubernetes and would like to share computing and administrative resources.
- Each tenant is a single team developing a single workload.
- Other than the application/service teams, there are other teams that also utilize and manage clusters, including platform team members, cluster administrators, auditors, etc.
- The platform team owns the clusters and defines the amount of resources each tenant team can use; each tenant can request more.
- Each tenant team should be able to deploy their application through the Kubernetes API without having to communicate with the platform team.
- Each tenant should not be able to affect other tenants in the shared cluster, except via explicit design decisions like API calls, shared data sources, etc.
Access Control
TBD
Network Policies
TBD
Resource Quotas
TBD
AAI Data Model
AAI CNF Model - Overview
...