Versions Compared

Key

  • This line was added.
  • This line was removed.
  • Formatting was changed.

Table of Contents


Introduction

The rApp Manager is a lifecycle management service for rApps. It gets the rApp as ASD formatted package and lifecycle manages it based on it instance configuration. It uses ONAP ACM for lifecycle management operations and it integrates with other components for managing the rApp.

ASD package contains the details required to create and integrate the required services/components. Each ASD package contains only one rApp and One rApp can have any number of rApp instances.

Integrations

The rApp Manager integrated with the below components to support lifecycle managing the rApp.

ACM

Automation Composition Management (ACM) is a framework that supports Life Cycle Management of Automation Compositions. It supports deployment, monitoring, update and removal of Automation Compositions en-bloc, allowing users to manage their features, services, and capabilities as single logical units. More details about ACM can be found here.

ACM-R supports any number of participants and all the participants can be configured through the configuration in the rApp package.

List of participants used by rApp manager sample rApp.

  • A1PMS Participant - It interacts with A1PMS of NONRTRIC. It is capable of lifecycle managing A1PMS service.
  • Kserve Participant - It interacts with Kserve. It is capable of lifecycle managing Kserve inference service.
  • Kubernetes Participant - It interacts with Helm/Kubernetes. It is capable of lifecycle managing Helm charts.
  • DME Participant -  It interacts with DME(ICS) of NONRTRIC. It is capable of lifecycle managing DME entities.

ACM composition and instance details can be provided as part of rApp package and the package structure can be found here.

DME

The DME(Information Coordination Service (ICS)) is a generic service that maintains data subscriptions. Its main purpose is to decouple data consumers and data producers in a multi vendor environment. A data consumer does not need to know anything about the producers of the data. More details about DME can be found here.

It integrates with rApp manager to enable the rApp produce/consume specific type of data(Information Type in DME terms).

Information type, Data producer/consumer information can be provided as part of rApp package and the package structure can be found here.

SME

The SME(CAPIF) stands for Common API framework and it was developed by 3GPP to enable a unified Northbound API framework across 3GPP network functions, and to ensure that there is a single and harmonized approach for API development. More details about DME can be found here.

It integrates with rApp manager to enable the rApp expose/access/discover endpoints.

Service exposure/access related configurations can be provided as part of rApp package and the package structure can be found here.


State Transitions

rApp States

The rApp lifecycle contains 4 states. The state and transitions are as follows,






  1. COMMISSIONED
  2. PRIMING
  3. PRIMED
  4. DEPRIMING

Image Added


rApp Instance States

The rApp Instance lifecycle contains 4 states. The state and transitions are as follows,






  1. UNDEPLOYED
  2. DEPLOYING
  3. DEPLOYED
  4. UNDEPLOYING

Image Added


Flows

rApp flow

Create rApp:

  1. API user creates rApp by sending rApp package
  2. rApp Manager validates the rApp
  3. rApp Manager stores the rApp in the file system if the rApp is valid
  4. API user provided with the status of rApp creation.
  5. API user request to Prime the rApp
  6. rApp Manager fetches the ACM composition from rApp package and 
    creates the ACM composition in ACM-R
  7. rApp Manager gets the ACM composition creation status from ACM-R
  8. rApp Manager request ACM-R to prime the ACM composition 
  9. rApp Manager gets the ACM composition priming status from ACM-R
  10. rApp Manager checks with DME for the unknown information type from rApp package
  11. rApp Manager get the information type availability from DME
  12. API user provided with the status of rApp priming

Delete rApp:

  1. API user request to Deprime rApp
  2. rApp Manager request ACM-R to deprime the ACM composition 
  3. rApp Manager get the status of ACM composition depriming.
  4. rApp Manager requests ACM-R to delete the ACM composition 
  5. rApp Manager gets the status of ACM composition deletion
  6. API user provided with the deprime rApp status.
  7. API user request to delete the rApp
  8. rApp Manager validates that the rApp is in COMMISSIONED state and 
    there is no rApp Instances are available.
  9. API User provided with delete rApp status

Image Added


rApp Instance flow

The rApp lifecycle contains 4 states. The state and transitions are as follows,


Create rApp Instance

  1. API user request to create rApp Instance with the resource details from rApp package
  2. API user get the rApp instance creation response

Deploy rApp Instance

  1. API user request to deploy rApp instance
  2. rApp Manager fetches the rApp package from file system and fetches the resources mentioned in the rApp instance.


  1. rApp Manager request ACM-R with the necessary details from rApp package to Instantiate and deploy ACM instance
  2. ACM-R deploys the A1PMS instance if it is configured in the ACM instance
  3. ACM-R gets the A1PMS deployment status
  4. ACM-R deploys the Kserve instance if it is configured in the ACM instance
  5. ACM-R gets the Kserve deployment status
  6. ACM-R deploys the Kubernetes instance if it is configured in the ACM instance
  7. ACM-R gets the Kubernetes deployment status
  8. ACM-R deploys the DME instance if it is configured in the ACM instance
  9. ACM-R gets the DME deployment status
  10. rApp Manager gets ACM deployment status

Image Added



Sample rApp package structure (This is a prototype and subject to change)

CSAR File Generation


Deployment Instructions