...
# | Actor | Action |
1 | Designer | •Design ASD and/or CBA |
2 | Designer / SDC | •Onboard SOL004-based ASD package (could include CBA) •Design Resource & Compose Resources into Service •Enhance ASD (ASD’) |
3 | SDC | •Distribute Service CSAR to ONAP runtime components (SO, AAI, SDNC, etc.) •Distribute ASD + ASD’ to Catalog Manager •Distribute Helm Charts to Helm Repository (centralized) •Distribute Images to Image Repository (centralized) |
4 | SO Client | •Start CNF service creation |
5 | SO | •S1: create service instance to AAI •S2: resolve parameters •S3: CDS returns assignment •Process model & decide flows (in this case, Helm Orchestrator) •Delegate Resource-level orchestration to Helm Orchestrator •Pass ASD’ or its reference with input (resolved) parameters |
6 | Helm Orchestrator | •Retrieve ASD’ (and/or ASD : TBD) from Catalog Manager |
7 | Helm Orchestrator | •Retrieve Helm Charts from Helm Repository |
Helm Orchestrator | •Transform ASD cloud artifacts with parameters to K8S resource description •Get additional data as needed | |
8,9 | Placement | •Get placement information |
10 | Helm Orchestrator | •Send CNF creation request to K8S |
11 | k8S | •Retrieve images from Image Repository and process for CNF |
12 | SO | Update CNF to AAI |
Onboard package – this will ingest the package, and verify the integrity and authenticity of the package etc.SDC supports ASD packages in addition to ETSI packagesboth ASD and ETSI packages conform to ETSI SOL004SDC transforms vendor ASD to internal ASD (proposal: ASD specification = internal ASD specification)
Store relevant information in repo – for internal organization and making the package available for deployment.SDC creates Service CSAR for the ASD AND ETSI VNF/CNFDService CSAR includes both vendor ASD and internal ASD
Descriptors will be stored in the Catalog Manager RepositoryHelm Charts will be stored in the Helm RepositoryImages will be stored in the Image Repository
Receive deployment order, along with required parameters. The required parameters are the ones specified in the ASD under “lifecycleParameters”.SO receives incoming Service Requests and retrieves the corresponding Service CatalogSo validates required parameters
Fetch descriptors from Service package.SO decomposes incoming Service Requests into ResourcesIf the resource is for CNF and ASD-based models, SO follows the ASD orchestration pathIf the resource is for ETSI-based models, SO delegates its orchestration to SO NFVO or VFC
SO delegates ASD orchestration to the Helm Processor (Helm v3)SO passes Descriptor (ASD) information and required parameters (e.g., lifecycleParameters) to the Helm Processor
Helm V3 handles internal ASD-based NF or applicationHelm V3 retrieves Helm Charts from the RepositoryUsing received parameters and default values already in the chart to construct the value files (custom yaml files and will be stored in the database).With this input, Helm performs a chart render; i.e., translates the charts into concrete K8S resources descriptions.
In the placement use case, the concrete K8S workload description (pod, daemonset, deployment, replicaset, statefulset, job, cronjobs, etc) and the ASD will be used by internal logic of orchestrator for placement decision.Perform placement decision – the placement function can parse the workload descriptors and ASD and use that information to select the appropriate cluster.Use Helm to install the application on a particular cluster with the values constructed in the Helm ProcessorHelm V3 does dry-run before real deployment; i.e., render templates with the right valuesIf generating the manifest and verifying the YAML file are only purpose, helm template can be considered
If dry-run is satisfied, Helm V3 sends its requests to K8S
ASD-based CNF Orchestration Realization Scenario
...