Objectives

• Enable use of CDS for self-service LCM operations currently supported by APPC and SDNC

• Identify target architecture for LCM API consolidation across different controllers: APPC, SDNC including CDS

• Identify migration path need

• Identify ONAP recommendations in case of

  • Supporting PNFs for applicable LCM operations
  • How and where to describe standard actions/operations including input parameters in payload

  • Adding a new LCM operation

  • A new UC/sw contribution with current LCM operations

• Frankfurt way forward

To Do's

• Identify target architecture and recommended evolution for the Frankfurt (R6) release

• Establish LCM API principles and recommendations

• Conclude migration path need for APPC/SDNC

•  Identify component candidates for CCSDK

Target Architecture

• SO/Policy communicate to GnfC using grpc via Self Service API.

gNFC can provide  1) direct connection to node via Chef/Netconf/Ansible adapters

                               2) direct connection to VIMs

                               2) adapters for external systems (i.e. EM or 3PP VNFM). SOL003 and SOL002 adapters have been discussed

                               3) can provide interworking with other internal components 

Takamune Cho , Dan Timoney : comments are welcome to reach a consensus across PTL controllers

Background - SO workflows in Dublin

SO supports service and resource workflows built from BPMN building blocks. Workflows are used e g for instantiation, scaling and change management. Some of the building blocks correspond to an LCM action towards controller (APPC/SDNC). Other building blocks send requests to AAI, GR-API (SDNC), VNF adapter or SOL-003 adapter.

Example below shows a change management activity building block using APPC client. In Dublin CDS is not used by SO except for configAssign and configDeploy. Another limitation is that PNFs are not supported by the generic building block framework and so far need to use custom BPMN workflows.

Frankfurt Step

Current best thinking for Frankfurt is to support multiple controller APIs by branching within SO based information in the distributed models (TOSCA/CSAR).

A more detailed diagram of this solution is shown below. The Java code called from BPMN would be extended to select either current path for APPC/SDNC or a CDS path. For PNFs there is a need to also update the building block framework to fully support the PNF resource type and then create either shared VNF/PNF or dedicated PNF building blocks.

To follow up: Request to have diagram showing also the SOL-003 adapter and how it relates to the other components.

SO impacts in Frankfurt

How to implement the selection of the controller in SO in a model driven approach.

Alexis de Talhouët , Seshu Kumar Mudiganti  to provide an input for the next meeting.

--

Following the same pattern used to select the homing solution, SO could implement the selection of the controller LCM endpoint.

This would required the following:

• creation of a placeholder in the userParams section of the SO request, along with acceptable values for it

  • proposal: LCM_API as placeholder. APPC and GNFC as values

          "userParams": [
            {
              "LCM_API": "APPC" or "GNFC"
            }
          ]
    
    

    • This will impact the WorkflowAction.java class that would need to set the appropriate variable in the BPMN context; see here for homing example: https://github.com/onap/so/blob/master/bpmn/so-bpmn-tasks/src/main/java/org/onap/so/bpmn/infrastructure/workflow/tasks/WorkflowAction.java#L332-L345
• An LCM BPMN with a conditional block based on the value able to build and trigger the request on the right system, similar as https://github.com/onap/so/blob/master/bpmn/so-bpmn-tasks/src/main/java/org/onap/so/bpmn/buildingblock/HomingV2.java and https://github.com/onap/so/blob/master/bpmn/so-bpmn-building-blocks/src/main/resources/subprocess/BuildingBlock/HomingBB.bpmn
• A well know list of potential LCM action provided by GNFC
• A client to GNFC (already done)

(Oskar Malm) The approach outlined above requires run-time input from the operator. I would like to propose a bit different high-level principles for further discussion:

• The resource/service designer may attach CDS blueprint(s) to resource or service (= resource customization). This indicates that blueprint shall be used for self-service LCM actions. TBD: Blueprint presence enough as selector, or need for additional model data/properties. Level of granularity - which actions are handled by each blueprint?
• The designer will not indicate specific controller to be used
• At run-time the SO building block will use only model data from design-time to conclude whether CDS path and API shall be used. (Until now, only SDNC deploys the blueprint processor mS. If in the future multiple personas or instances would deploy the blueprint processor, additional logic must be defined to select which one to use.)

LCM API principles and recommendations in Frankfurt

A convergency between API  controllers should start in Frankfurt.

In case a new operation need to be introduce in the NBI controller, it is reccomended the gRPC SSAPI

Other possible architecture option discussed for Frankfurt

A number of other architectural options exist.

Example below would move selection and use of controller API out of main SO module. Feedback is that option A is better first step for Frankfurt. 

If SO cannot implement option A in Frankfurt,  other implementation options, as option B, can be considered.

El Alto improvements

• External SOL003 Adapter as an Independent deployable component  (in relation to VNF LCM and Orchestration track)
  
  

Contributions...