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

Compare with Current View Page History

« Previous Version 32 Next »

Target release: Jakarta (it could be changed)


Note: this is based on the current ASD concept understanding. This would be a PoC use case to prove the usage of ASD and interactions of southbound interfaces (e.g., Kubernetes)


Goals:

  • ASD onboarding to SDC, including:
    • ASD integration with Service Model in SDC, including internal mapping
      • Proposal: use the ASD model as SDC internal model
    • Allow SDC designers to customize/add custom properties ? e.g., defining input parameters, adding custom properties...
  • SDC distribution to ONAP Runtime components
    • Store ONAP internal Descriptors in Catalog Manager
    • Store Helm Charts in Helm Chart Repository
    • Store Images in Image Repository
  • Orchestration based on ASD-model
    • Orchestrators get Helm information
      • not repeating resource information that is defined in Helm Charts
      • demonstrate how ASD and Helm Charts are processed by the orchestrator 
  • Dry Run

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-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
  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
    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 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
    1. SO passes Descriptor (ASD) information and required parameters (e.g., lifecycleParameters) to the Helm Processor
  6. Helm Processor handles 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 in the selected O-Cloud.
  9. Use Helm to install the application on a particular cluster with the values constructed in the Helm Processor
    1. Helm Processor do dry-run before sending its requests to K8S


Interfaces

SDC Onboarding

SDC and Catalog Manager

SDC and Helm Repository

SDC and Image Repository

OSS/BSS and SO

SO and Helm Processor

Helm Processor and Placement

Helm Processor and Helm Client

Helm Client and O-Cloud (K8S)


Components (Functions and Requirements)

Helm Repository

Image Repository

Helm Processor

Placement


  • No labels