Table of Contents |
---|
- ASD PoC Target release: Kohn
- PoC is now completed!!
- ASD Contribution Target release:
...
- London
Note: this is based on the current ASD concept understanding. This would be a PoC use case to prove ASD usage (onboarding/distribution) and interactions of southbound interfaces (e.g., Kubernetes)
Goals:
POC Outcome and Presentation
- Presentation at the LFN DTF November, Seattle USA:
CloudNativeOrchestrationUsingASD-11-18-2022-Final.pdf
See the https://wiki.lfnetworking.org/pages/viewpage.action?pageId=80281744 for recording
- Sample free5gc ASD package:
ASD Design & Orchestration Overview
Goals:
- ASD onboarding to SDC, including:
- Allow SDC designers to customize/add custom properties ? e.g., defining input parameters, adding custom properties...
- Store original vendor
- Allow SDC designers to customize/add custom properties ? e.g., defining input parameters, adding custom properties...
- Store original vendor packages
- Store enhanced ASD descriptors
- Transforming onboarding ASD packages into internal ASD model
- Proposal: use the ASD model as SDC internal model (TBD_
- leverage SDC Multi Model support feature, creation of distinct notification for ASD, ETSI and HEAT...
- ASD integration with Service Model in SDC
- SDC distribution to ONAP Runtime components
- Store internal ASD Descriptors in Catalog Manager
- Store Helm Charts in Helm Chart Repository
- Store Images in Image Repository
- Orchestration based on internal ASD-model
- Orchestrators (Helm v3) get Helm Chart
- demonstrate how internal ASD and Helm Charts are processed by the orchestrator
- Resolve K8 resources based on input parameters and Cloud Artifacts
- send requests to Kubernetes
...
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
Sequence Steps:
...
#
...
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
...
CNF Manager
...
- Retrieve ASD’ (and/or ASD : TBD) from Catalog Manager
...
7
...
CNF Manager
...
- Retrieve Helm Charts from Helm Repository
...
CNF Manager
...
- Transform ASD cloud artifacts with parameters to K8S resource description (e.g., helm template or helm install --dry-run)
- Get additional data as needed
...
8
...
CNF Manager
...
- Get placement information by passing K8 resources + ASD' + additional data to the Placement
...
- make a placement decision based on input data & return it
...
10
...
CNF Manager
...
- Send CNF creation request (with cluster id, parameter, cloud artifacts) to K8S (e.g., helm install ...)
...
11
...
k8S
...
- Retrieve images from Image Repository and process for CNF
...
12
...
SO
...
- Update CNF to AAI
Diagram for Jakarta
Gliffy Diagram macroId b714f8c2-f5c2-49b4-b67a-9b29a3375d80 name ASD onboarding and distribution - Jakarta pagePin 1
helm install --dry-run or --debug vs. helm template
- helm install –-dry-run or --debug
Gliffy Diagram | ||||||||
---|---|---|---|---|---|---|---|---|
|
- helm template
Gliffy Diagram | ||||||
---|---|---|---|---|---|---|
|
Sequence Steps:
# | Actor | Action |
1 | Designer |
|
2 | Designer / SDC |
|
3 | SDC |
|
4 | SO Client |
|
5 | SO |
|
6 | CNF Manager |
|
7 | CNF Manager |
|
CNF Manager |
| |
8 | CNF Manager |
|
9 | Placement |
|
10 | CNF Manager |
|
11 | k8S |
|
12 | SO |
|
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
The following process depicts the ASD-based CNF orchestration scenario, leveraging CDS (future consideration)
Gliffy Diagram | ||||||||
---|---|---|---|---|---|---|---|---|
|
ASD Package
The following diagram depicts ASD package, conforming to SOL004.
Note: the App (xApp, rApp) package structure will be added here once the specification is available. Most likely, xApp and rApp support is not part of the initial PoC.
Gliffy Diagram | ||||||||
---|---|---|---|---|---|---|---|---|
|
ASD & Package Examples
For the ASD and Package examples, see the ASD & packaging examples.
A "Sample" Application Model in TOSCA (note: this is a work in progress (by Ericsson); to be refined further)
Based on the example of the ONAP webpage, https://wiki.onap.org/pages/viewpage.action?pageId=103422195
Some Underlying Data and Node Types
SDC Onboarding
SDC onboarding process will be enhanced to handle ASD.
- Package Delivery: A vendor delivers an SOL004-based ASD package
- Pre-Onboarding for validation: TBD (out of PoC scope)
- Onboarding: SDC brings in and stores resources such as xNF, xApp and rApp into ONAP for later use in services.
Onboarding SDC Design Consideration (in progress)
- SDC supports multiple models, e.g., SDC model, ETSI model, vendor/operator specific models
- SDC supports onboarding, design and packaging of services/resources that adhere to any of the supported models instead of just the SDC model
- SDC can extend its multiple models to handle ASD model
- SDC supports translation between models where appropriate/wanted, e.g., translation of ASD model to SDC model
- A type is added to the DB schema to define models (e.g., SDC model would be one instance, ETSI SO001 would be another, ASD would be another)
- When adding node types, data types, etc. in SDC, they can be associated with one or more models
- Id of the types must be set to ensure types with the same name can exist in different models
- On creating a new service:
- Select the model applicable to the service
- Only resources from that model, or based on that model, can be used in designing the service
- Ensures, for example, that only ETSI types can be used when designing a ETSI NS
- Where non SDC model is selected, the topology template is constructed without any ONAP specific structuring
- Option to generate a service that is a mapping of the created (e.g. ETSI NS) service in the ONAP SDC model and using ONAP structure
- This will be a separate service, but with the option to auto update as required
- Automated generation for convenience, but creating as a separate service allows the user the opportunity to fine tune to address any gaps or short comings in the translation logic
- Distribution: It will be possible to distinguish ONAP from non-ONAP services in the distribution notification
- Onboarding a VSP:
- Select the model applicable to the VSP
- Validator used in onboarding is selected based on the specified model
- VF generated using the types from the specified model
- Where new types are defined in the csar, a new model is created which is specific to the csar
- Where ONAP model is selected, VF is import as today
- Where another model is selected, the VF is created using the types defined for that model, and using standard TOSCA structure (e.g. the substitutable as node type is preserved in the generated VF)
- Option to generate a VF that is a mapping of the created VF in the ONAP SDC model and structure (similar to what is proposed for services)
Onboarding Information Flow
SDC needs to support the following onboarding process.
Note: ASD package validation is not addressed here. TBD
PlantUML Macro | ||
---|---|---|
| ||
@startuml
participant VENDOR
participant ONAPUSER
participant SDC
autonumber
group ASD PACKAGE DELIVERY
hnote over ONAPUSER : Vendor ASD Package Delivery
VENDOR -> ONAPUSER : ASD Package Delivery
end
group Create a resource
hnote over SDC : Options to create a resource in SDC
group Onboarding
group Options
hnote over SDC : Two onboarding options
group PACKAGE ONBOARDING
hnote over SDC : Create a VSP model using onboarding ASD package
ONAPUSER -> SDC : onboarding an ASD package
SDC -> SDC : Create an internal model with Metadata added
SDC -> SDC : Transform onboarding artifacts into SDC onboarding
SDC -> SDC : Transform onboarding descriptor into internal descriptor
SDC -> SDC : License Model Files Added (optional)
end
group Manual ASD VSP creation
hnote over SDC : Manual create an ASD VSP model
ONAPUSER -> SDC : Create a CNF VSP model
SDC -> SDC : Create an internal model with Metadata added
ONAPUSER -> SDC : Update internal descriptor properties
ONAPUSER -> SDC : License Model Files Added (optional)
ONAPUSER -> SDC : Artifacts Added
end
end
end
group Create a resource
group Create resource from a VSP
hnote over SDC : Create resource model from a VSP
ONAPUSER -> SDC : Create a resource from a CNF VSP
SDC -> SDC : Transform a VSP into a resource model
SDC -> SDC : update internal descriptor properties
SDC -> SDC : update License Model Files (optional)
ONAPUSER -> SDC : Additional Artifacts Added (Manual/Optional)
end
group Manual create an ASD resource
hnote over SDC : Manual create an ASD Resource
SDC -> SDC : create an internal ASD model with Metadata added
ONAPUSER -> SDC : Update internal descriptor properties\nnote: ONAP users update default properties
ONAPUSER -> SDC : License Model Files Added (optional)
ONAPUSER -> SDC : Additional Artifacts Added (Manual/Optional)
end
end
end
@enduml |
ASD Packaging Onboarding Summary - a VSP model is created using an Onboarding ASD package
- The onboarding ASD package is accessed by a Technology specialist/Asset manager.
- An internal model is created in SDC with Metadata added.
- The artifacts from the ASD package are transformed into onboarding artifacts during SDC onboarding
- SDC transforms the ASD onboarding descriptor into an SDC internal descriptor
- Optionally, License model files are added
Manual ASD VSP Creation Summary - an ASD VSP model is manually created
- The Technology specialist/Asset manager initiates a manual VSP creation.
- SDC is used to create an internal model with Metadata added.
- The internal descriptor proprieties are updated. The vendor provided descriptor can specify attribute value limitations or ranges
- The License Model Files are then added to the VSP
- The License Model Files are then added to the VSP (Optional)
Create Resource - from a VSP
- The ONAP Operator requests for a resource to be created from a VSP
- An VSP is transformed into a resource model.
- The SDC Internal descriptor properties are updated. Customized types during design time allows service providers to specify additional restrictions on onboarded parameters.
- For example a vendor specified attribute might have allowed values
- customized types would restrict certain allowed values.
- The License Model Files are then added to the VSP
- The License Model Files are then added to the VSP (Optional)
Create Resource - Manual Creation of ASD Resource
- The operator invokes the manual creation of an ASD resource. An internal ASD model is created with Metadata added.
- In SDC, the internal descriptor properties are updated by the ONAP user.
- License model files can be added by the user in SDC.
- The operator may add additional artifacts to the resource (optional). The resource becomes available in the SDC catalog for use in service creation.
Design Service
- The Service Designer composes resource descriptors into a Service descriptor.
- The Service Designer attaches service-specific flows, such as FM, Configuration, Accounting, PM, security.
Gliffy Diagram | ||||||||
---|---|---|---|---|---|---|---|---|
|
SDC Internal Package for ASD
The following depicts SDC internal package for ASD.
Gliffy Diagram | ||||||
---|---|---|---|---|---|---|
|
- SDC adds an UUID identifier
- SDC adds additional TOSCA Metadata
- SDC transforms ASD into internal models
- SDC can add a license model file
- The user may optionally add additional artifacts manually
Mapping between ASD and SDC internal model
- ASD specification is relatively simple
- Propose to use ASD specification as the SDC internal model
Application Service Descriptor | SDC AID DM (Internal Data Model) - VNF/CNF | ||||||||||
---|---|---|---|---|---|---|---|---|---|---|---|
Attribute | Qualifier | Cardinality | Content | Description | Attribute | Qualifier | Cardinality | Content | Description | ||
asdId | M | 1 | Identifier | ||||||||
asdSchemaVersion | M | 1 | Version | ||||||||
asdProvider | M | 1 | String | ||||||||
asdApplicationName | M | 1 | String | ||||||||
asdApplicationVersion | M | 1 | Version | ||||||||
asdApplicationInfoName | M / O | 0..1 | String | ||||||||
asdInfoDescription | M / O | 0..1 | String | ||||||||
asdExtCpd | M / O | 0..1 | dataType.ExtCpd | ||||||||
enhancedClusterCapabilities | M / O | 0..1 | dataType.enhancedClusterCapabilities | ||||||||
deploymentItems | M | 1..N | DeploymentItem |
Application Service Descriptor > DeploymentItems | SDC AID DM (Internal Data Model) - VF Module | ||||||||||
---|---|---|---|---|---|---|---|---|---|---|---|
Attribute | Qualifier | Cardinality | Content | Description | Attribute | Qualifier | Cardinality | Content | Description | ||
deploymentItemId | M | 1 | Identifier | ||||||||
artifactId | M | 1 | Identifier (reference to) | ||||||||
artifactType | M | 1 | String/enum | ||||||||
deploymentOrder | M | 1 | String | ||||||||
lifecycleParameters | M | 1 | String |
Enhancement of SDC Internal ASD model
- SDC allows SDC designers to customize/add custom properties when it creates internal ASD models
- SDC UI allows the user to define necessary input parameters and add custom resource properties...
- in that case, enhanced ASD can contain most of resource information for the orchestration by SO/Helm v3
- SDC stores the original vendor ASD packages
- SDC allows SDC designers to customize/add custom properties when it creates internal ASD models
Package Distribution
The following depicts SDC Service CSAR distribution and storage.
Gliffy Diagram | ||||||||
---|---|---|---|---|---|---|---|---|
|
- SDC sends package notifications to DMaaP for its subscribers (Catalog Manager, SO, other ONAP runtime components)
- Catalog Manager queries ASD descriptors once it gets a package notification from SDC via DMaaP
- note: the current ONAP runtime Catalog Manager handles ETSI packages. we may extend it to handle ASD. TBD
- SDC pushes Helm Charts to the target Helm Repository
- SDC pushes Images to the target Image Repository
- Note: SDC will support large-size images
- Catalog Manager, Helm Repository and Image Repository are centralized in the PoC. Domain-specific repositories will be considered in the future.
LCM Orchestration
The following diagram depicts ASD orchestration for LCM.
Gliffy Diagram | ||||||||
---|---|---|---|---|---|---|---|---|
|
- A deployment order is received, along with the required parameter values
- The cloud-native deployment tool is invoked with the received parameters to transform the cloud artifacts into K8S resource descriptions
The K8S resource descriptions, ASD and any other relevant data is sent to the placement function
Placement decision is done based on input data
Inform deployment of placement
Request the cloud native deployment tool to deploy on the identified target cluster
- Cloud native deployment tool deploys application in the chosen cluster using the K8S API
Component Functional Enhancements
SDC
CDS
SDNC
SO
SO Helm Adapter (extend the SO K8S Adapter??)
Catalog Manager (extend the ETSI Catalog Manager??)
Helm Process (a.k.a. Helm v3)
Helm Repository
Image Repository
OOF
AAI
Policy
Interfaces
SDC Onboarding
- SDCE-1
SDC and Catalog Manager
- TBD
- should we leverage the Model_catalog component which was designed for ETSI package???
SDC and Helm Repository
- TBD
SDC and Image Repository
- TBD
OSS/BSS (or SO Client) and SO
- SO NBI
SO and Helm Processor
- TBD
Helm Processor and Placement
- TBD
Helm Processor and Helm Client
- TBD
Helm Client and O-Cloud (K8S)
- Kubernetes APIs
Components (Functions and Requirements)
Helm Repository
Image Repository
Helm Processor
Placement
Table of Contents |
---|
Target release: Jakarta
Note: this is based on the current ASD concept understanding. This would be a PoC use case to prove ASD usage (onboarding/distribution) and interactions of southbound interfaces (e.g., Kubernetes)
Goals:
- ASD onboarding to SDC, including:
- Allow SDC designers to customize/add custom properties ? e.g., defining input parameters, adding custom properties...
- Store original vendor packages
- Store enhanced ASD descriptors
- Transforming onboarding ASD packages into internal ASD model
- Proposal: use the ASD model as SDC internal model
- ASD integration with Service Model in SDC
- SDC distribution to ONAP Runtime components
- Store internal ASD Descriptors in Catalog Manager
- Store Helm Charts in Helm Chart Repository
- Store Images in Image Repository
- Orchestration based on internal ASD-model
- Orchestrators (Helm v3) get Helm Chart
- demonstrate how internal ASD and Helm Charts are processed by the orchestrator (e.g.
- perform Dry Run in Helm v3
- send requests to Kubernetes
Helm 3 Interaction between Helm Client and Kubernetes API Server
Helm 3 has a client-only architecture with the client. In Helm 3, the client interacts directly with the Kubernetes API server The in-cluster server Tiller is removed.
Gliffy Diagram | ||||||
---|---|---|---|---|---|---|
|
ASD Onboarding and Orchestration PoC Architecture
The architecture conforms to the above Helm3 client-only architecture.
The following diagram depicts ASD onboarding and orchestration PoC.
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
Sequence Steps:
- 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 V3 handles internal ASD-based NF or application
- Helm V3 retrieves Helm Charts from the Repository
- Using 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 Processor
- Helm 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 its requests to K8S
- Helm V3 does dry-run before real deployment; i.e., render templates with the right values
ASD-based CNF Orchestration Realization Scenario
The following process depicts the ASD-based CNF orchestration scenario.
Gliffy Diagram | ||||||||
---|---|---|---|---|---|---|---|---|
|
ASD Package
The following diagram depicts ASD package, conforming to SOL004.
Note: the App (xApp, rApp) package structure will be added here once the specification is available. Most likely, xApp and rApp support is not part of the initial PoC.
Gliffy Diagram | ||||||||
---|---|---|---|---|---|---|---|---|
|
ASD & Package Examples
For the ASD and Package examples, see the ASD & packaging examples.
A "Sample" Application Model in TOSCA (note: this is a work in progress (by Ericsson); to be refined further)
Based on the example of the ONAP webpage, https://wiki.onap.org/pages/viewpage.action?pageId=103422195
Some Underlying Data and Node Types
SDC Onboarding
SDC onboarding process will be enhanced to handle ASD.
- Package Delivery: A vendor delivers an SOL004-based ASD package
- Pre-Onboarding for validation: TBD (out of PoC scope)
- Onboarding: SDC brings in and stores resources such as xNF, xApp and rApp into ONAP for later use in services.
Onboarding Information Flow
SDC needs to support the following onboarding process.
Note: ASD package validation is not addressed here. TBD
PlantUML Macro | ||
---|---|---|
| ||
@startuml
participant VENDOR
participant ONAPUSER
participant SDC
autonumber
group ASD PACKAGE DELIVERY
hnote over ONAPUSER : Vendor ASD Package Delivery
VENDOR -> ONAPUSER : ASD Package Delivery
end
group Create a resource
hnote over SDC : Options to create a resource in SDC
group Onboarding
group Options
hnote over SDC : Two onboarding options
group PACKAGE ONBOARDING
hnote over SDC : Create a VSP model using onboarding ASD package
ONAPUSER -> SDC : onboarding an ASD package
SDC -> SDC : Create an internal model with Metadata added
SDC -> SDC : Transform onboarding artifacts into SDC onboarding
SDC -> SDC : Transform onboarding descriptor into internal descriptor
SDC -> SDC : License Model Files Added (optional)
end
group Manual ASD VSP creation
hnote over SDC : Manual create an ASD VSP model
ONAPUSER -> SDC : Create a CNF VSP model
SDC -> SDC : Create an internal model with Metadata added
ONAPUSER -> SDC : Update internal descriptor properties
ONAPUSER -> SDC : License Model Files Added (optional)
ONAPUSER -> SDC : Artifacts Added
end
end
end
group Create a resource
group Create resource from a VSP
hnote over SDC : Create resource model from a VSP
ONAPUSER -> SDC : Create a resource from a CNF VSP
SDC -> SDC : Transform a VSP into a resource model
SDC -> SDC : update internal descriptor properties
SDC -> SDC : update License Model Files (optional)
ONAPUSER -> SDC : Additional Artifacts Added (Manual/Optional)
end
group Manual create an ASD resource
hnote over SDC : Manual create an ASD Resource
SDC -> SDC : create an internal ASD model with Metadata added
ONAPUSER -> SDC : Update internal descriptor properties\nnote: ONAP users update default properties
ONAPUSER -> SDC : License Model Files Added (optional)
ONAPUSER -> SDC : Additional Artifacts Added (Manual/Optional)
end
end
end
@enduml |
ASD Packaging Onboarding Summary - a VSP model is created using an Onboarding ASD package
- The onboarding ASD package is accessed by a Technology specialist/Asset manager.
- An internal model is created in SDC with Metadata added.
- The artifacts from the ASD package are transformed into onboarding artifacts during SDC onboarding
- SDC transforms the ASD onboarding descriptor into an SDC internal descriptor
- Optionally, License model files are added
Manual ASD VSP Creation Summary - an ASD VSP model is manually created
- The Technology specialist/Asset manager initiates a manual VSP creation.
- SDC is used to create an internal model with Metadata added.
- The internal descriptor proprieties are updated. The vendor provided descriptor can specify attribute value limitations or ranges
- The License Model Files are then added to the VSP
- The License Model Files are then added to the VSP (Optional)
Create Resource - from a VSP
- The ONAP Operator requests for a resource to be created from a VSP
- An VSP is transformed into a resource model.
- The SDC Internal descriptor properties are updated. Customized types during design time allows service providers to specify additional restrictions on onboarded parameters.
- For example a vendor specified attribute might have allowed values
- customized types would restrict certain allowed values.
- The License Model Files are then added to the VSP
- The License Model Files are then added to the VSP (Optional)
Create Resource - Manual Creation of ASD Resource
- The operator invokes the manual creation of an ASD resource. An internal ASD model is created with Metadata added.
- In SDC, the internal descriptor properties are updated by the ONAP user.
- License model files can be added by the user in SDC.
- The operator may add additional artifacts to the resource (optional). The resource becomes available in the SDC catalog for use in service creation.
Design Service
- The Service Designer composes resource descriptors into a Service descriptor.
- The Service Designer attaches service-specific flows, such as FM, Configuration, Accounting, PM, security.
Gliffy Diagram | ||||||||
---|---|---|---|---|---|---|---|---|
|
SDC Internal Package for ASD
The following depicts SDC internal package for ASD.
Gliffy Diagram | ||||||
---|---|---|---|---|---|---|
|
- SDC adds an UUID identifier
- SDC adds additional TOSCA Metadata
- SDC transforms ASD into internal models
- SDC can add a license model file
- The user may optionally add additional artifacts manually
Mapping between ASD and SDC internal model
- ASD specification is relatively simple
- Propose to use ASD specification as the SDC internal model
Application Service Descriptor | SDC AID DM (Internal Data Model) - VNF/CNF | ||||||||||
---|---|---|---|---|---|---|---|---|---|---|---|
Attribute | Qualifier | Cardinality | Content | Description | Attribute | Qualifier | Cardinality | Content | Description | ||
asdId | M | 1 | Identifier | ||||||||
asdSchemaVersion | M | 1 | Version | ||||||||
asdProvider | M | 1 | String | ||||||||
asdApplicationName | M | 1 | String | ||||||||
asdApplicationVersion | M | 1 | Version | ||||||||
asdApplicationInfoName | M / O | 0..1 | String | ||||||||
asdInfoDescription | M / O | 0..1 | String | ||||||||
asdExtCpd | M / O | 0..1 | dataType.ExtCpd | ||||||||
enhancedClusterCapabilities | M / O | 0..1 | dataType.enhancedClusterCapabilities | ||||||||
deploymentItems | M | 1..N | DeploymentItem |
Application Service Descriptor > DeploymentItems | SDC AID DM (Internal Data Model) - VF Module | ||||||||||
---|---|---|---|---|---|---|---|---|---|---|---|
Attribute | Qualifier | Cardinality | Content | Description | Attribute | Qualifier | Cardinality | Content | Description | ||
deploymentItemId | M | 1 | Identifier | ||||||||
artifactId | M | 1 | Identifier (reference to) | ||||||||
artifactType | M | 1 | String/enum | ||||||||
deploymentOrder | M | 1 | String | ||||||||
lifecycleParameters | M | 1 | String |
Enhancement of SDC Internal ASD model
- SDC allows SDC designers to customize/add custom properties when it creates internal ASD models
- SDC UI allows the user to define necessary input parameters and add custom resource properties...
- in that case, enhanced ASD can contain most of resource information for the orchestration by SO/Helm v3
- SDC stores the original vendor ASD packages
- SDC allows SDC designers to customize/add custom properties when it creates internal ASD models
Package Distribution
The following depicts SDC Service CSAR distribution and storage.
Gliffy Diagram | ||||||||
---|---|---|---|---|---|---|---|---|
|
- SDC sends package notifications to DMaaP for its subscribers (Catalog Manager, SO, other ONAP runtime components)
- Catalog Manager queries ASD descriptors once it gets a package notification from SDC via DMaaP
- note: the current ONAP runtime Catalog Manager handles ETSI packages. we may extend it to handle ASD. TBD
- SDC pushes Helm Charts to the target Helm Repository
- SDC pushes Images to the target Image Repository
- Note: SDC will support large-size images
- Catalog Manager, Helm Repository and Image Repository are centralized in the PoC. Domain-specific repositories will be considered in the future.
LCM Orchestration
The following diagram depicts ASD orchestration for LCM.
Gliffy Diagram | ||||||||
---|---|---|---|---|---|---|---|---|
|
- A deployment order is received, along with the required parameter values
- The cloud-native deployment tool is invoked with the received parameters to transform the cloud artifacts into K8S resource descriptions
The K8S resource descriptions, ASD and any other relevant data is sent to the placement function
Placement decision is done based on input data
Inform deployment of placement
Request the cloud native deployment tool to deploy on the identified target cluster
- Cloud native deployment tool deploys application in the chosen cluster using the K8S API
Component Functional Enhancements
SDC
CDS
SDNC
SO
SO Helm Adapter (extend the SO K8S Adapter??)
Catalog Manager (extend the ETSI Catalog Manager??)
Helm Process (a.k.a. Helm v3)
Helm Repository
Image Repository
OOF
AAI
Policy
Interfaces
SDC Onboarding
- SDCE-1
SDC and Catalog Manager
- TBD
- should we leverage the Model_catalog component which was designed for ETSI package???
SDC and Helm Repository
- TBD
SDC and Image Repository
- TBD
OSS/BSS (or SO Client) and SO
- SO NBI
SO and Helm Processor
- TBD
Helm Processor and Placement
- TBD
Helm Processor and Helm Client
- TBD
Helm Client and O-Cloud (K8S)
- Kubernetes APIs
Components (Functions and Requirements)
Helm Repository
Image Repository
Helm Processor
Placement
Table of Contents |
---|
Target release: Jakarta
Note: this is based on the current ASD concept understanding. This would be a PoC use case to prove ASD usage (onboarding/distribution) and interactions of southbound interfaces (e.g., Kubernetes)
Goals:
- ASD onboarding to SDC, including:
- Allow SDC designers to customize/add custom properties ? e.g., defining input parameters, adding custom properties...
- Store original vendor packages
- Store enhanced ASD descriptors
- Transforming onboarding ASD packages into internal ASD model
- use the ASD model as SDC internal model (TBD_
- leverage SDC Multi Model support feature, creation of distinct notification for ASD, ETSI and HEAT...
- ASD integration with Service Model in SDC
- SDC distribution to ONAP Runtime components
- Store internal ASD Descriptors in Catalog Manager
- Store Helm Charts in Helm Chart Repository
- Store Images in Image Repository
- Orchestration based on internal ASD-model
- Orchestrators (Helm v3) get Helm Chart
- demonstrate how internal ASD and Helm Charts are processed by the orchestrator
- Resolve K8 resources based on input parameters and Cloud Artifacts
- send requests to Kubernetes
Helm 3 Interaction between Helm Client and Kubernetes API Server
Helm 3 has a client-only architecture with the client. In Helm 3, the client interacts directly with the Kubernetes API server The in-cluster server Tiller is removed.
Gliffy Diagram | ||||||
---|---|---|---|---|---|---|
|
ASD Onboarding and Orchestration PoC Architecture
The architecture conforms to the above Helm3 client-only architecture.
The following diagram depicts ASD onboarding and orchestration PoC.
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
helm install --dry-run or --debug vs. helm template
- helm install –-dry-run or --debug
Gliffy Diagram | ||||||||
---|---|---|---|---|---|---|---|---|
|
- helm template
Gliffy Diagram | ||||||
---|---|---|---|---|---|---|
|
Sequence Steps:
# | Actor | Action |
1 | Designer |
|
2 | Designer / SDC |
|
3 | SDC |
|
4 | SO Client |
|
5 | SO |
|
6 | CNF Manager |
|
7 | CNF Manager |
|
CNF Manager |
| |
8 | CNF Manager |
|
9 | Placement |
|
10 | CNF Manager |
|
11 | k8S |
|
12 | SO |
|
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
The following process depicts the ASD-based CNF orchestration scenario.
Gliffy Diagram | ||||||||
---|---|---|---|---|---|---|---|---|
|
ASD Package
The following diagram depicts ASD package, conforming to SOL004.
Note: the App (xApp, rApp) package structure will be added here once the specification is available. Most likely, xApp and rApp support is not part of the initial PoC.
Gliffy Diagram | ||||||||
---|---|---|---|---|---|---|---|---|
|
ASD & Package Examples
For the ASD and Package examples, see the ASD & packaging examples.
A "Sample" Application Model in TOSCA (note: this is a work in progress (by Ericsson); to be refined further)
Based on the example of the ONAP webpage, https://wiki.onap.org/pages/viewpage.action?pageId=103422195
Some Underlying Data and Node Types
SDC Onboarding
SDC onboarding process will be enhanced to handle ASD.
- Package Delivery: A vendor delivers an SOL004-based ASD package
- Pre-Onboarding for validation: TBD (out of PoC scope)
- Onboarding: SDC brings in and stores resources such as xNF, xApp and rApp into ONAP for later use in services.
Onboarding SDC Design Consideration (in progress)
- SDC supports multiple models, e.g., SDC model, ETSI model, vendor/operator specific models
- SDC supports onboarding, design and packaging of services/resources that adhere to any of the supported models instead of just the SDC model
- SDC can extend its multiple models to handle ASD model
- SDC supports translation between models where appropriate/wanted, e.g., translation of ASD model to SDC model
- A type is added to the DB schema to define models (e.g., SDC model would be one instance, ETSI SO001 would be another, ASD would be another)
- When adding node types, data types, etc. in SDC, they can be associated with one or more models
- Id of the types must be set to ensure types with the same name can exist in different models
- On creating a new service:
- Select the model applicable to the service
- Only resources from that model, or based on that model, can be used in designing the service
- Ensures, for example, that only ETSI types can be used when designing a ETSI NS
- Where non SDC model is selected, the topology template is constructed without any ONAP specific structuring
- Option to generate a service that is a mapping of the created (e.g. ETSI NS) service in the ONAP SDC model and using ONAP structure
- This will be a separate service, but with the option to auto update as required
- Automated generation for convenience, but creating as a separate service allows the user the opportunity to fine tune to address any gaps or short comings in the translation logic
- Distribution: It will be possible to distinguish ONAP from non-ONAP services in the distribution notification
- Onboarding a VSP:
- Select the model applicable to the VSP
- Validator used in onboarding is selected based on the specified model
- VF generated using the types from the specified model
- Where new types are defined in the csar, a new model is created which is specific to the csar
- Where ONAP model is selected, VF is import as today
- Where another model is selected, the VF is created using the types defined for that model, and using standard TOSCA structure (e.g. the substitutable as node type is preserved in the generated VF)
- Option to generate a VF that is a mapping of the created VF in the ONAP SDC model and structure (similar to what is proposed for services)
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
The following process depicts the ASD-based CNF orchestration scenario.
Gliffy Diagram | ||||||||
---|---|---|---|---|---|---|---|---|
|
ASD Package
The following diagram depicts ASD package, conforming to SOL004.
Note: the App (xApp, rApp) package structure will be added here once the specification is available. Most likely, xApp and rApp support is not part of the initial PoC.
Gliffy Diagram | ||||||||
---|---|---|---|---|---|---|---|---|
|
ASD & Package Examples
For the ASD and Package examples, see the ASD & packaging examples.
A "Sample" Application Model in TOSCA (note: this is a work in progress (by Ericsson); to be refined further)
Based on the example of the ONAP webpage, https://wiki.onap.org/pages/viewpage.action?pageId=103422195
Some Underlying Data and Node Types
SDC Onboarding
SDC onboarding process will be enhanced to handle ASD.
- Package Delivery: A vendor delivers an SOL004-based ASD package
- Pre-Onboarding for validation: TBD (out of PoC scope)
- Onboarding: SDC brings in and stores resources such as xNF, xApp and rApp into ONAP for later use in services.
Onboarding Information Flow
SDC needs to support the following onboarding process.
Note: ASD package validation is not addressed here. TBD
PlantUML Macro | ||
---|---|---|
| ||
@startuml
participant VENDOR
participant ONAPUSER
participant SDC
autonumber
group ASD PACKAGE DELIVERY
hnote over ONAPUSER : Vendor ASD Package Delivery
VENDOR -> ONAPUSER : ASD Package Delivery
end
group Create a resource
hnote over SDC : Options to create a resource in SDC
group Onboarding
group Options
hnote over SDC : Two onboarding options
group PACKAGE ONBOARDING
hnote over SDC : Create a VSP model using onboarding ASD package
ONAPUSER -> SDC : onboarding an ASD package
SDC -> SDC : Create an internal model with Metadata added
SDC -> SDC : Transform onboarding artifacts into SDC onboarding
SDC -> SDC : Transform onboarding descriptor into internal descriptor
SDC -> SDC : License Model Files Added (optional)
end
group Manual ASD VSP creation
hnote over SDC : Manual create an ASD VSP model
ONAPUSER -> SDC : Create a CNF VSP model
SDC -> SDC : Create an internal model with Metadata added
ONAPUSER -> SDC : Update internal descriptor properties
ONAPUSER -> SDC : License Model Files Added (optional)
ONAPUSER -> SDC : Artifacts Added
end
end
end
group Create a resource
group Create resource from a VSP
hnote over SDC : Create resource model from a VSP
ONAPUSER -> SDC : Create a resource from a CNF VSP
SDC -> SDC : Transform a VSP into a resource model
SDC -> SDC : update internal descriptor properties
SDC -> SDC : update License Model Files (optional)
ONAPUSER -> SDC : Additional Artifacts Added (Manual/Optional)
end
group Manual create an ASD resource
hnote over SDC : Manual create an ASD Resource
SDC -> SDC : create an internal ASD model with Metadata added
ONAPUSER -> SDC : Update internal descriptor properties\nnote: ONAP users update default properties
ONAPUSER -> SDC : License Model Files Added (optional)
ONAPUSER -> SDC : Additional Artifacts Added (Manual/Optional)
end
end
end
@enduml |
ASD Packaging Onboarding Summary - a VSP model is created using an Onboarding ASD package
- The onboarding ASD package is accessed by a Technology specialist/Asset manager.
- An internal model is created in SDC with Metadata added.
- The artifacts from the ASD package are transformed into onboarding artifacts during SDC onboarding
- SDC transforms the ASD onboarding descriptor into an SDC internal descriptor
- Optionally, License model files are added
Manual ASD VSP Creation Summary - an ASD VSP model is manually created
- The Technology specialist/Asset manager initiates a manual VSP creation.
- SDC is used to create an internal model with Metadata added.
- The internal descriptor proprieties are updated. The vendor provided descriptor can specify attribute value limitations or ranges
- The License Model Files are then added to the VSP
- The License Model Files are then added to the VSP (Optional)
Create Resource - from a VSP
- The ONAP Operator requests for a resource to be created from a VSP
- An VSP is transformed into a resource model.
- The SDC Internal descriptor properties are updated. Customized types during design time allows service providers to specify additional restrictions on onboarded parameters.
- For example a vendor specified attribute might have allowed values
- customized types would restrict certain allowed values.
- The License Model Files are then added to the VSP
- The License Model Files are then added to the VSP (Optional)
Create Resource - Manual Creation of ASD Resource
- The operator invokes the manual creation of an ASD resource. An internal ASD model is created with Metadata added.
- In SDC, the internal descriptor properties are updated by the ONAP user.
- License model files can be added by the user in SDC.
- The operator may add additional artifacts to the resource (optional). The resource becomes available in the SDC catalog for use in service creation.
Design Service
- The Service Designer composes resource descriptors into a Service descriptor.
- The Service Designer attaches service-specific flows, such as FM, Configuration, Accounting, PM, security.
Gliffy Diagram | ||||||||
---|---|---|---|---|---|---|---|---|
|
SDC Internal Package for ASD
The following depicts SDC internal package for ASD.
Gliffy Diagram | ||||||
---|---|---|---|---|---|---|
|
- SDC adds an UUID identifier
- SDC adds additional TOSCA Metadata
- SDC transforms ASD into internal models
- SDC can add a license model file
- The user may optionally add additional artifacts manually
Mapping between ASD and SDC internal model
- ASD specification is relatively simple
- Propose to use ASD specification as the SDC internal model
...
Enhancement of SDC Internal ASD model
- SDC allows SDC designers to customize/add custom properties when it creates internal ASD models
- SDC UI allows the user to define necessary input parameters and add custom resource properties...
- in that case, enhanced ASD can contain most of resource information for the orchestration by SO/Helm v3
- SDC stores the original vendor ASD packages
- SDC allows SDC designers to customize/add custom properties when it creates internal ASD models
Package Distribution
The following depicts SDC Service CSAR distribution and storage.
Gliffy Diagram | ||||||||
---|---|---|---|---|---|---|---|---|
|
- SDC sends package notifications to DMaaP for its subscribers (Catalog Manager, SO, other ONAP runtime components)
- Catalog Manager queries ASD descriptors once it gets a package notification from SDC via DMaaP
- note: the current ONAP runtime Catalog Manager handles ETSI packages. we may extend it to handle ASD. TBD
- SDC pushes Helm Charts to the target Helm Repository
- SDC pushes Images to the target Image Repository
- Note: SDC will support large-size images
- Catalog Manager, Helm Repository and Image Repository are centralized in the PoC. Domain-specific repositories will be considered in the future.
LCM Orchestration
The following diagram depicts ASD orchestration for LCM.
Gliffy Diagram | ||||||||
---|---|---|---|---|---|---|---|---|
|
- A deployment order is received, along with the required parameter values
- The cloud-native deployment tool is invoked with the received parameters to transform the cloud artifacts into K8S resource descriptions
The K8S resource descriptions, ASD and any other relevant data is sent to the placement function
Placement decision is done based on input data
Inform deployment of placement
Request the cloud native deployment tool to deploy on the identified target cluster
- Cloud native deployment tool deploys application in the chosen cluster using the K8S API
Component Functional Enhancements
SDC
CDS
SDNC
SO
SO Helm Adapter (extend the SO K8S Adapter??)
Catalog Manager (extend the ETSI Catalog Manager??)
Helm Process (a.k.a. Helm v3)
Helm Repository
Image Repository
OOF
AAI
Policy
Interfaces
SDC Onboarding
- SDCE-1
SDC and Catalog Manager
- TBD
- should we leverage the Model_catalog component which was designed for ETSI package???
SDC and Helm Repository
- TBD
SDC and Image Repository
- TBD
OSS/BSS (or SO Client) and SO
- SO NBI
SO and Helm Processor
- TBD
Helm Processor and Placement
- TBD
Helm Processor and Helm Client
- TBD
Helm Client and O-Cloud (K8S)
- Kubernetes APIs
Components (Functions and Requirements)
Helm Repository
Image Repository
Helm Processor
Placement
Table of Contents |
---|
Target release: Jakarta
Note: this is based on the current ASD concept understanding. This would be a PoC use case to prove ASD usage (onboarding/distribution) and interactions of southbound interfaces (e.g., Kubernetes)
Goals:
- ASD onboarding to SDC, including:
- Allow SDC designers to customize/add custom properties ? e.g., defining input parameters, adding custom properties...
- Store original vendor packages
- Store enhanced ASD descriptors
- Transforming onboarding ASD packages into internal ASD model
- Proposal: use the ASD model as SDC internal model
- ASD integration with Service Model in SDC
- SDC distribution to ONAP Runtime components
- Store internal ASD Descriptors in Catalog Manager
- Store Helm Charts in Helm Chart Repository
- Store Images in Image Repository
- Orchestration based on internal ASD-model
- Orchestrators (Helm v3) get Helm Chart
- demonstrate how internal ASD and Helm Charts are processed by the orchestrator (e.g.
- perform Dry Run in Helm v3
- send requests to Kubernetes
Helm 3 Interaction between Helm Client and Kubernetes API Server
Helm 3 has a client-only architecture with the client. In Helm 3, the client interacts directly with the Kubernetes API server The in-cluster server Tiller is removed.
Gliffy Diagram | ||||||
---|---|---|---|---|---|---|
|
ASD Onboarding and Orchestration PoC Architecture
The architecture conforms to the above Helm3 client-only architecture.
The following diagram depicts ASD onboarding and orchestration PoC.
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
Sequence Steps:
- 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 V3 handles internal ASD-based NF or application
- Helm V3 retrieves Helm Charts from the Repository
- Using 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 Processor
- Helm 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 its requests to K8S
- Helm V3 does dry-run before real deployment; i.e., render templates with the right values
ASD-based CNF Orchestration Realization Scenario
The following process depicts the ASD-based CNF orchestration scenario.
Gliffy Diagram | ||||||||
---|---|---|---|---|---|---|---|---|
|
ASD Package
The following diagram depicts ASD package, conforming to SOL004.
Note: the App (xApp, rApp) package structure will be added here once the specification is available. Most likely, xApp and rApp support is not part of the initial PoC.
Gliffy Diagram | ||||||||
---|---|---|---|---|---|---|---|---|
|
ASD & Package Examples
For the ASD and Package examples, see the ASD & packaging examples.
A "Sample" Application Model in TOSCA (note: this is a work in progress (by Ericsson); to be refined further)
Based on the example of the ONAP webpage, https://wiki.onap.org/pages/viewpage.action?pageId=103422195
Some Underlying Data and Node Types
SDC Onboarding
SDC onboarding process will be enhanced to handle ASD.
- Package Delivery: A vendor delivers an SOL004-based ASD package
- Pre-Onboarding for validation: TBD (out of PoC scope)
- Onboarding: SDC brings in and stores resources such as xNF, xApp and rApp into ONAP for later use in services.
...
Onboarding Information Flow
SDC needs to support the following onboarding process.
...
PlantUML Macro | ||
---|---|---|
| ||
@startuml participant VENDOR participant ONAPUSER participant SDC autonumber group ASD PACKAGE DELIVERY hnote over ONAPUSER : Vendor ASD Package Delivery VENDOR -> ONAPUSER : ASD Package Delivery end group Create a resource hnote over SDC : Options to create a resource in SDC group Onboarding group Options hnote over SDC : Two onboarding options group PACKAGE ONBOARDING hnote over SDC : Create a VSP model using onboarding ASD package ONAPUSER -> SDC : onboarding an ASD package SDC -> SDC : Create an internal model with Metadata added SDC -> SDC : Transform onboarding artifacts into SDC onboarding SDC -> SDC : Transform onboarding descriptor into internal descriptor SDC -> SDC : License Model Files Added (optional) end group Manual ASD VSP creation hnote over SDC : Manual create an ASD VSP model ONAPUSER -> SDC : Create a CNF VSP model SDC -> SDC : Create an internal model with Metadata added ONAPUSER -> SDC : Update internal descriptor properties ONAPUSER -> SDC : License Model Files Added (optional) ONAPUSER -> SDC : Artifacts Added end end end group Create a resource group Create resource from a VSP hnote over SDC : Create resource model from a VSP ONAPUSER -> SDC : Create a resource from a CNF VSP SDC -> SDC : Transform a VSP into a resource model SDC -> SDC : update internal descriptor properties SDC -> SDC : update License Model Files (optional) ONAPUSER -> SDC : Additional Artifacts Added (Manual/Optional) end group Manual create an ASD resource hnote over SDC : Manual create an ASD Resource SDC -> SDC : create an internal ASD model with Metadata added ONAPUSER -> SDC : Update internal descriptor properties\nnote: ONAP users update default properties ONAPUSER -> SDC : License Model Files Added (optional) ONAPUSER -> SDC : Additional Artifacts Added (Manual/Optional) end end end @enduml |
ASD Packaging Onboarding Summary - a VSP model is created using an Onboarding ASD package
- The onboarding ASD package is accessed by a Technology specialist/Asset manager.
- An internal model is created in SDC with Metadata added.
- The artifacts from the ASD package are transformed into onboarding artifacts during SDC onboarding
- SDC transforms the ASD onboarding descriptor into an SDC internal descriptor
- Optionally, License model files are added
Manual ASD VSP Creation Summary - an ASD VSP model is manually created
- The Technology specialist/Asset manager initiates a manual VSP creation.
- SDC is used to create an internal model with Metadata added.
- The internal descriptor proprieties are updated. The vendor provided descriptor can specify attribute value limitations or ranges
- The License Model Files are then added to the VSP
- The License Model Files are then added to the VSP (Optional)
Create Resource - from a VSP
- The ONAP Operator requests for a resource to be created from a VSP
- An VSP is transformed into a resource model.
- The SDC Internal descriptor properties are updated. Customized types during design time allows service providers to specify additional restrictions on onboarded parameters.
- For example a vendor specified attribute might have allowed values
- customized types would restrict certain allowed values.
- The License Model Files are then added to the VSP
- The License Model Files are then added to the VSP (Optional)
Create Resource - Manual Creation of ASD Resource
- The operator invokes the manual creation of an ASD resource. An internal ASD model is created with Metadata added.
- In SDC, the internal descriptor properties are updated by the ONAP user.
- License model files can be added by the user in SDC.
- The operator may add additional artifacts to the resource (optional). The resource becomes available in the SDC catalog for use in service creation.
Design Service
- The Service Designer composes resource descriptors into a Service descriptor.
- The Service Designer attaches service-specific flows, such as FM, Configuration, Accounting, PM, security.
Gliffy Diagram | ||||||||
---|---|---|---|---|---|---|---|---|
|
SDC Internal Package for ASD
The following depicts SDC internal package for ASD.
...
- SDC adds an UUID identifier
- SDC adds additional TOSCA Metadata
- SDC transforms ASD into internal models
- SDC can add a license model file
- The user may optionally add additional artifacts manually
Mapping between ASD and SDC internal model
- ASD specification is relatively simple
- Propose to use ASD specification as the SDC internal model
...
Application Service Descriptor > DeploymentItems | SDC AID DM (Internal Data Model) - VF Module | ||||||||||
---|---|---|---|---|---|---|---|---|---|---|---|
Attribute | Qualifier | Cardinality | Content | Description | Attribute | Qualifier | Cardinality | Content | Description | ||
deploymentItemId | M | 1 | Identifier | ||||||||
artifactId | M | 1 | Identifier (reference to) | ||||||||
artifactType | M | 1 | String/enum | ||||||||
deploymentOrder | M | 1 | String | ||||||||
lifecycleParameters | M | 1 | String |
Enhancement of SDC Internal ASD model
- SDC allows SDC designers to customize/add custom properties when it creates internal ASD models
- SDC UI allows the user to define necessary input parameters and add custom resource properties...
- in that case, enhanced ASD can contain most of resource information for the orchestration by SO/Helm v3
- SDC stores the original vendor ASD packages
- SDC allows SDC designers to customize/add custom properties when it creates internal ASD models
Package Distribution
The following depicts SDC Service CSAR distribution and storage.
...
- SDC sends package notifications to DMaaP for its subscribers (Catalog Manager, SO, other ONAP runtime components)
- Catalog Manager queries ASD descriptors once it gets a package notification from SDC via DMaaP
- note: the current ONAP runtime Catalog Manager handles ETSI packages. we may extend it to handle ASD. TBD
- SDC pushes Helm Charts to the target Helm Repository
- SDC pushes Images to the target Image Repository
- Note: SDC will support large-size images
- Catalog Manager, Helm Repository and Image Repository are centralized in the PoC. Domain-specific repositories will be considered in the future.
LCM Orchestration
The following diagram depicts ASD orchestration for LCM.
...
- A deployment order is received, along with the required parameter values
- The cloud-native deployment tool is invoked with the received parameters to transform the cloud artifacts into K8S resource descriptions
The K8S resource descriptions, ASD and any other relevant data is sent to the placement function
Placement decision is done based on input data
Inform deployment of placement
Request the cloud native deployment tool to deploy on the identified target cluster
- Cloud native deployment tool deploys application in the chosen cluster using the K8S API
Component Functional Enhancements
SDC
CDS
SDNC
SO
SO Helm Adapter (extend the SO K8S Adapter??)
Catalog Manager (extend the ETSI Catalog Manager??)
Helm Process (a.k.a. Helm v3)
Helm Repository
Image Repository
OOF
AAI
Policy
Interfaces
SDC Onboarding
- SDCE-1
SDC and Catalog Manager
- TBD
- should we leverage the Model_catalog component which was designed for ETSI package???
SDC and Helm Repository
- TBD
SDC and Image Repository
- TBD
OSS/BSS (or SO Client) and SO
- SO NBI
SO and Helm Processor
- TBD
Helm Processor and Placement
- TBD
Helm Processor and Helm Client
...
Helm Client and O-Cloud (K8S)
- Kubernetes APIs