...
Gliffy Diagram | ||||||||
---|---|---|---|---|---|---|---|---|
|
Note:
- ETSI SOL001-based model orchestration leveraging Helm Processor needs to be sort out further.
- Helm Processor realization (e.g., MultiCloud??, EMCO?? others??) will be discussed
- Placement realization (e.g., OOF?? others??) will be discussed
...
- 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 packages
- both ASD and ETSI packages conform to ETSI SOL004
- SDC 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/CNFD
- Service CSAR includes both vendor ASD and internal ASD
- Descriptors will be stored in the Catalog Manager Repository
- Helm Charts will be stored in the Helm Repository
- Images will be stored in the Image Repository
- SDC creates Service CSAR for the ASD AND ETSI VNF/CNFD
- 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 Catalog
- So validates required parameters
- Fetch descriptors from Service package.
- SO decomposes incoming Service Requests into Resources
- If the resource is for CNF and ASD-based models, SO follows the ASD orchestration path
- If 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 Processor handles internal ASD-based NF or application
- Helm Processor retrieves Helm Charts from the Repository
- Using received parameters and default values already in the chart to construct the value files.
- 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 Processor
- Helm Processor do V3 does dry-run before real deployment; i.e., render templates with the right values
- If generating the manifest and verifying the YAML file are only purpose, helm template can be considered
- If dry-run is satisfied, Helm V3 sends sending its requests to K8S
- Helm Processor do V3 does dry-run before real deployment; i.e., render templates with the right values
ASD Package
The following diagram depicts ASD package, conforming to SOL004.
Gliffy Diagram | ||||||
---|---|---|---|---|---|---|
|
SDC Onboarding
- Package Delivery: A vendor delivers an SOL004-based ASD package
- Pre-Onboarding for validation: TBD
- Onboarding: SDC brings in and stores resources such as xNF, xApp and rApp into ONAP for later use in services.
...