You are viewing an old version of this page. View the current version.

Compare with Current View Page History

« Previous Version 71 Next »

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.

Helm 3 Client Architecture


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.


ASD onboarding and orchestration PoC

Note:

  1. ETSI SOL001-based model orchestration leveraging Helm Processor needs to be sort out further. 
  2. Helm Processor realization (e.g., MultiCloud??, EMCO?? others??) will be discussed
  3. Placement realization (e.g., OOF?? others??) will be discussed


Sequence Steps:

  1. Onboard package – this will ingest the package, and verify the integrity and authenticity of the package etc.
    1. SDC supports ASD packages in addition to ETSI packages
    2. both ASD and ETSI packages conform to ETSI SOL004
    3. SDC transforms vendor ASD to internal ASD (proposal: ASD specification = internal ASD specification)
  2. Store relevant information in repo – for internal organization and making the package available for deployment.
    1. SDC creates Service CSAR for the ASD AND ETSI VNF/CNFD
      1. Service CSAR includes both vendor ASD and internal ASD
    2. Descriptors will be stored in the Catalog Manager Repository
    3. Helm Charts will be stored in the Helm Repository
    4. Images will be stored in the Image Repository
  3. Receive deployment order, along with required parameters. The required parameters are the ones specified in the ASD under “lifecycleParameters”.
    1. SO receives incoming Service Requests and retrieves the corresponding Service Catalog
    2. So validates required parameters
  4. Fetch descriptors from Service package.
    1. SO decomposes incoming Service Requests into Resources
    2. If the resource is for CNF and ASD-based models, SO follows the ASD orchestration path
    3. If the resource is for ETSI-based models, SO delegates its orchestration to SO NFVO or VFC
  5. SO delegates ASD orchestration to the Helm Processor (Helm v3)
    1. SO passes Descriptor (ASD) information and required parameters (e.g., lifecycleParameters) to the Helm Processor
  6. Helm V3 handles internal ASD-based NF or application
    1. Helm V3 retrieves Helm Charts from the Repository
    2. 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).
    3. With this input, Helm performs a chart render; i.e., translates the charts into concrete K8S resources descriptions.
  7. 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.
  8. Perform placement decision – the placement function can parse the workload descriptors and ASD and use that information to select the appropriate cluster.
  9. Use Helm to install the application on a particular cluster with the values constructed in the Helm Processor
    1. Helm V3 does dry-run before real deployment; i.e., render templates with the right values
      1. If generating the manifest and verifying the YAML file are only purpose, helm template can be considered
    2. If dry-run is satisfied, Helm V3 sends its requests to K8S


Deployment Process Scenario

The following process depicts the deployment scenario.



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.


ASD package structure

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. 

Onboarding Information Flow

SDC needs to support the following onboarding process.

Note: ASD package validation is not addressed here. TBD ASD Onboarding VENDOR VENDOR ONAPUSER ONAPUSER SDC SDC ASD PACKAGE DELIVERY Vendor Package Delivery 1ASD Package Delivery Create a resource Options to create a resource in SDC Onboarding Options Two onboarding options PACKAGE ONBOARDING Create a VSP model using onboarding ASD package 2Create a CNF VSP model 3Create an internal model with Metadata added 4Transform onboarding artifacts into SDC onboarding 5Transform onboarding descriptor into internal descriptor(proposal: use ASD models as internal models) 6License Model Files Added (optional) Manual ASD VSP creation Manual create a ASD VSP model 7Create a CNF VSP model 8Create an internal model with Metadata added 9Update internal descriptor properties 10License Model Files Added (optional) 11Artifacts Added Create a resource Create resource from a VSP Create resource model from a VSP 12Create a resource from a CNF VSP 13Transform a VSP into a resource model 14update internal descriptor properties 15update License Model Files (optional) 16Additional Artifacts Added (Manual/Optional) Manual create an ASD resource Manual create ASD Resources 17create an internal ASD model with Metadata added 18Update internal descriptor properties 19License Model Files Added (optional) 20Additional Artifacts Added (Manual/Optional)

SDC Internal Package for ASD

The following depicts SDC internal package for ASD.


ASD onboarding and distribution

  • 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

Package Distribution

The following depicts SDC Service CSAR distribution and storage.


SDC ASD Service CSAR distribution

  • 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

TBD

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


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.

Helm 3 Client Architecture


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.


ASD onboarding and orchestration PoC

Note:

  1. ETSI SOL001-based model orchestration leveraging Helm Processor needs to be sort out further. 
  2. Helm Processor realization (e.g., MultiCloud??, EMCO?? others??) will be discussed
  3. Placement realization (e.g., OOF?? others??) will be discussed


Sequence Steps:

  1. Onboard package – this will ingest the package, and verify the integrity and authenticity of the package etc.
    1. SDC supports ASD packages in addition to ETSI packages
    2. both ASD and ETSI packages conform to ETSI SOL004
    3. SDC transforms vendor ASD to internal ASD (proposal: ASD specification = internal ASD specification)
  2. Store relevant information in repo – for internal organization and making the package available for deployment.
    1. SDC creates Service CSAR for the ASD AND ETSI VNF/CNFD
      1. Service CSAR includes both vendor ASD and internal ASD
    2. Descriptors will be stored in the Catalog Manager Repository
    3. Helm Charts will be stored in the Helm Repository
    4. Images will be stored in the Image Repository
  3. Receive deployment order, along with required parameters. The required parameters are the ones specified in the ASD under “lifecycleParameters”.
    1. SO receives incoming Service Requests and retrieves the corresponding Service Catalog
    2. So validates required parameters
  4. Fetch descriptors from Service package.
    1. SO decomposes incoming Service Requests into Resources
    2. If the resource is for CNF and ASD-based models, SO follows the ASD orchestration path
    3. If the resource is for ETSI-based models, SO delegates its orchestration to SO NFVO or VFC
  5. SO delegates ASD orchestration to the Helm Processor (Helm v3)
    1. SO passes Descriptor (ASD) information and required parameters (e.g., lifecycleParameters) to the Helm Processor
  6. Helm Processor handles internal ASD-based NF or application
    1. Helm Processor retrieves Helm Charts from the Repository
    2. Using received parameters and default values already in the chart to construct the value files.
    3. With this input, Helm performs a chart render; i.e., translates the charts into concrete K8S resources descriptions.
  7. 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.
  8. Perform placement decision – the placement function can parse the workload descriptors and ASD and use that information to select the appropriate cluster.
  9. Use Helm to install the application on a particular cluster with the values constructed in the Helm Processor
    1. Helm V3 does dry-run before real deployment; i.e., render templates with the right values
      1. If generating the manifest and verifying the YAML file are only purpose, helm template can be considered
    2. If dry-run is satisfied, Helm V3 sends its requests to K8S


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.


ASD package structure

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. 

Onboarding Information Flow

SDC needs to support the following onboarding process.

Note: ASD package validation is not addressed here. TBD ASD Onboarding VENDOR VENDOR ONAPUSER ONAPUSER SDC SDC ASD PACKAGE DELIVERY Vendor Package Delivery 1ASD Package Delivery Create a resource Options to create a resource in SDC Onboarding Options Two onboarding options PACKAGE ONBOARDING Create a VSP model using onboarding ASD package 2Create a CNF VSP model 3Create an internal model with Metadata added 4Transform onboarding artifacts into SDC onboarding 5Transform onboarding descriptor into internal descriptor(proposal: use ASD models as internal models) 6License Model Files Added (optional) Manual ASD VSP creation Manual create a ASD VSP model 7Create a CNF VSP model 8Create an internal model with Metadata added 9Update internal descriptor properties 10License Model Files Added (optional) 11Artifacts Added Create a resource Create resource from a VSP Create resource model from a VSP 12Create a resource from a CNF VSP 13Transform a VSP into a resource model 14update internal descriptor properties 15update License Model Files (optional) 16Additional Artifacts Added (Manual/Optional) Manual create an ASD resource Manual create ASD Resources 17create an internal ASD model with Metadata added 18Update internal descriptor properties 19License Model Files Added (optional) 20Additional Artifacts Added (Manual/Optional)

SDC Internal Package for ASD

The following depicts SDC internal package for ASD.


ASD onboarding and distribution

  • 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

Package Distribution

The following depicts SDC Service CSAR distribution and storage.


SDC ASD Service CSAR distribution

  • 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

TBD

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


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.

Helm 3 Client Architecture


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.


ASD onboarding and orchestration PoC

Note:

  1. ETSI SOL001-based model orchestration leveraging Helm Processor needs to be sort out further. 
  2. Helm Processor realization (e.g., MultiCloud??, EMCO?? others??) will be discussed
  3. Placement realization (e.g., OOF?? others??) will be discussed


Sequence Steps:

  1. Onboard package – this will ingest the package, and verify the integrity and authenticity of the package etc.
    1. SDC supports ASD packages in addition to ETSI packages
    2. both ASD and ETSI packages conform to ETSI SOL004
    3. SDC transforms vendor ASD to internal ASD (proposal: ASD specification = internal ASD specification)
  2. Store relevant information in repo – for internal organization and making the package available for deployment.
    1. SDC creates Service CSAR for the ASD AND ETSI VNF/CNFD
      1. Service CSAR includes both vendor ASD and internal ASD
    2. Descriptors will be stored in the Catalog Manager Repository
    3. Helm Charts will be stored in the Helm Repository
    4. Images will be stored in the Image Repository
  3. Receive deployment order, along with required parameters. The required parameters are the ones specified in the ASD under “lifecycleParameters”.
    1. SO receives incoming Service Requests and retrieves the corresponding Service Catalog
    2. So validates required parameters
  4. Fetch descriptors from Service package.
    1. SO decomposes incoming Service Requests into Resources
    2. If the resource is for CNF and ASD-based models, SO follows the ASD orchestration path
    3. If the resource is for ETSI-based models, SO delegates its orchestration to SO NFVO or VFC
  5. SO delegates ASD orchestration to the Helm Processor (Helm v3)
    1. SO passes Descriptor (ASD) information and required parameters (e.g., lifecycleParameters) to the Helm Processor
  6. Helm V3 handles internal ASD-based NF or application
    1. Helm V3 retrieves Helm Charts from the Repository
    2. 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).
    3. With this input, Helm performs a chart render; i.e., translates the charts into concrete K8S resources descriptions.
  7. 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.
  8. Perform placement decision – the placement function can parse the workload descriptors and ASD and use that information to select the appropriate cluster.
  9. Use Helm to install the application on a particular cluster with the values constructed in the Helm Processor
    1. Helm V3 does dry-run before real deployment; i.e., render templates with the right values
      1. If generating the manifest and verifying the YAML file are only purpose, helm template can be considered
    2. If dry-run is satisfied, Helm V3 sends its requests to K8S


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.


ASD package structure

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. 

Onboarding Information Flow

SDC needs to support the following onboarding process.

Note: ASD package validation is not addressed here. TBD ASD Onboarding VENDOR VENDOR ONAPUSER ONAPUSER SDC SDC ASD PACKAGE DELIVERY Vendor Package Delivery 1ASD Package Delivery Create a resource Options to create a resource in SDC Onboarding Options Two onboarding options PACKAGE ONBOARDING Create a VSP model using onboarding ASD package 2Create a CNF VSP model 3Create an internal model with Metadata added 4Transform onboarding artifacts into SDC onboarding 5Transform onboarding descriptor into internal descriptor(proposal: use ASD models as internal models) 6License Model Files Added (optional) Manual ASD VSP creation Manual create a ASD VSP model 7Create a CNF VSP model 8Create an internal model with Metadata added 9Update internal descriptor properties 10License Model Files Added (optional) 11Artifacts Added Create a resource Create resource from a VSP Create resource model from a VSP 12Create a resource from a CNF VSP 13Transform a VSP into a resource model 14update internal descriptor properties 15update License Model Files (optional) 16Additional Artifacts Added (Manual/Optional) Manual create an ASD resource Manual create ASD Resources 17create an internal ASD model with Metadata added 18Update internal descriptor properties 19License Model Files Added (optional) 20Additional Artifacts Added (Manual/Optional)

SDC Internal Package for ASD

The following depicts SDC internal package for ASD.


ASD onboarding and distribution

  • 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

Package Distribution

The following depicts SDC Service CSAR distribution and storage.


SDC ASD Service CSAR distribution

  • 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

TBD

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


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.

Helm 3 Client Architecture


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.


ASD onboarding and orchestration PoC

Note:

  1. ETSI SOL001-based model orchestration leveraging Helm Processor needs to be sort out further. 
  2. Helm Processor realization (e.g., MultiCloud??, EMCO?? others??) will be discussed
  3. Placement realization (e.g., OOF?? others??) will be discussed


Sequence Steps:

  1. Onboard package – this will ingest the package, and verify the integrity and authenticity of the package etc.
    1. SDC supports ASD packages in addition to ETSI packages
    2. both ASD and ETSI packages conform to ETSI SOL004
    3. SDC transforms vendor ASD to internal ASD (proposal: ASD specification = internal ASD specification)
  2. Store relevant information in repo – for internal organization and making the package available for deployment.
    1. SDC creates Service CSAR for the ASD AND ETSI VNF/CNFD
      1. Service CSAR includes both vendor ASD and internal ASD
    2. Descriptors will be stored in the Catalog Manager Repository
    3. Helm Charts will be stored in the Helm Repository
    4. Images will be stored in the Image Repository
  3. Receive deployment order, along with required parameters. The required parameters are the ones specified in the ASD under “lifecycleParameters”.
    1. SO receives incoming Service Requests and retrieves the corresponding Service Catalog
    2. So validates required parameters
  4. Fetch descriptors from Service package.
    1. SO decomposes incoming Service Requests into Resources
    2. If the resource is for CNF and ASD-based models, SO follows the ASD orchestration path
    3. If the resource is for ETSI-based models, SO delegates its orchestration to SO NFVO or VFC
  5. SO delegates ASD orchestration to the Helm Processor (Helm v3)
    1. SO passes Descriptor (ASD) information and required parameters (e.g., lifecycleParameters) to the Helm Processor
  6. Helm Processor handles internal ASD-based NF or application
    1. Helm Processor retrieves Helm Charts from the Repository
    2. Using received parameters and default values already in the chart to construct the value files.
    3. With this input, Helm performs a chart render; i.e., translates the charts into concrete K8S resources descriptions.
  7. 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.
  8. Perform placement decision – the placement function can parse the workload descriptors and ASD and use that information to select the appropriate cluster.
  9. Use Helm to install the application on a particular cluster with the values constructed in the Helm Processor
    1. Helm V3 does dry-run before real deployment; i.e., render templates with the right values
      1. If generating the manifest and verifying the YAML file are only purpose, helm template can be considered
    2. If dry-run is satisfied, Helm V3 sends its requests to K8S


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.


ASD package structure

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. 

Onboarding Information Flow

SDC needs to support the following onboarding process.

Note: ASD package validation is not addressed here. TBD ASD Onboarding VENDOR VENDOR ONAPUSER ONAPUSER SDC SDC ASD PACKAGE DELIVERY Vendor Package Delivery 1ASD Package Delivery Create a resource Options to create a resource in SDC Onboarding Options Two onboarding options PACKAGE ONBOARDING Create a VSP model using onboarding ASD package 2Create a CNF VSP model 3Create an internal model with Metadata added 4Transform onboarding artifacts into SDC onboarding 5Transform onboarding descriptor into internal descriptor(proposal: use ASD models as internal models) 6License Model Files Added (optional) Manual ASD VSP creation Manual create a ASD VSP model 7Create a CNF VSP model 8Create an internal model with Metadata added 9Update internal descriptor properties 10License Model Files Added (optional) 11Artifacts Added Create a resource Create resource from a VSP Create resource model from a VSP 12Create a resource from a CNF VSP 13Transform a VSP into a resource model 14update internal descriptor properties 15update License Model Files (optional) 16Additional Artifacts Added (Manual/Optional) Manual create an ASD resource Manual create ASD Resources 17create an internal ASD model with Metadata added 18Update internal descriptor properties 19License Model Files Added (optional) 20Additional Artifacts Added (Manual/Optional)

SDC Internal Package for ASD

The following depicts SDC internal package for ASD.


ASD onboarding and distribution

  • 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

Package Distribution

The following depicts SDC Service CSAR distribution and storage.


SDC ASD Service CSAR distribution

  • 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

TBD

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


  • No labels