Work in progress

Goal

• Migrate PNF PNP workflow to Building Blocks (BBs/GR_API).
• Include newly created BBs in Service-Macro-Create flow.
• Leave legacy implementation using VNF_API intact.

...

• Responsibility:
  
  • Waits for "PNF ready" event sent from PRH to DMaaP
    • pnfCorrelationId from the event must match PNF instance name provided by the user during service instantiation
  • Sets PNF orchestration status in AAI to:
    • Register - when starting to wait for PNF ready event
    • Registered - when PNF ready event is successfully received
• Currently implemented in CreateAndActivatePnfResource.bpmn

Support for config assign (ControllerExecutionBB

...

, action: configAssign)

• Responsibility:
  
  • Runs config assign via CDS
• Currently implemented in ConfigurePnfResource.bpmn
• We will reuse generic BPMN for calling CDS (ControllerExecutionBB)
• Things to consider:
  • SkipPostInstantiationConfiguration should be taken into account

Support for config deploy (ControllerExecutionBB

...

, action: configDeploy)

• Responsibility:
  
  • Runs config deploy via CDS
• Currently implemented in ConfigurePnfResource.bpmn
• We will reuse generic BPMN for calling CDS (ControllerExecutionBB)
• Things to consider:
  
  • SkipPostInstantiationConfiguration should be taken into account

...

1. AssignServiceInstanceBB
2. CreateNetworkCollectionBB
3. AssignNetworkBB
4. AssignVnfBB
5. AssignVolumeGroupBB
6. AssignVfModuleBB
7. AssignPnfBB
8. WaitForPnfReadyBB
9. ControllerExecutionBB (action: configAssign, scope: pnf)
10. ControllerExecutionBB (action: configDeploy, scope: pnf)
11. ActivatePnfBB
12. ConfigAssignVnfBB
13. CreateNetworkBB
14. ActivateNetworkBB
15. CreateVolumeGroupBB
16. ActivateVolumeGroupBB
17. CreateVfModuleBB
18. ActivateVfModuleBB
19. ConfigDeployVnfBB
20. ActivateVnfBB
21. ActivateNetworkCollectionBB
22. ActivateServiceInstanceBB

...

• Are all required PNF parameters included in GeneralBuildingBlock->ServiceInstance→Pnf? 
  • Currently those are:
    • pnf-id
    • pnf-name
    • role
    • orchestration-status
    • cloud-region
  • Currently AAI schema (aai_schema_v19.xsd) for PNF contains: 
    • Fields: pnf-name, pnf-name2, selflink, pnf-name2-source, pnf-id, equip-type, equip-vendor, equip-model, management-option, orchestration-status, ipaddress-v4-oam, sw-version, in-maint, frame-id, serial-number, ipaddress-v4-loopback-0, ipaddress-v6-loopback-0, ipaddress-v4-aim, ipaddress-v6-aim, ipaddress-v6-oam, inv-status, resource-version, prov-status, nf-role, admin-status, operational-status, model-customization-id, model-invariant-id, model-version-id (from SO cataloge), pnf-ipv4-address, pnf-ipv6-address
    • Sub-structures: software-versions, relationship-list, p-interfaces, lag-interfaces, vrfs
  •  BBInputSetup implementation does not mention PNF at all - is it even initialized in GeneralBuildingBlock?
  • PNF ip is resolved by CDS by PNF ID (it should be in AAI) - it's populated by PRH
• How to include new BBs in Service-Macro-Create flow?
  
  • Service decomposition in WorkflowActionBB may not unserstand PNFs (Retrieve BB Execution List)
  • Service decomposition should handle SkipPostInstantiationConfiguration
• PNF orchestration status changes in AAI - which states should be assigned in which steps of the workflow
• PNF SW upgrade (Oskar Malm)
  • PNF should be active - PNP is finished
  • new Upgrade flow will be created (BBs vs traditional considered)
• 5G NRM Configuration - plan for new BB which invokes configuration via CDS of NRM resource(?) (Yaoguang Wang, see https://wikilf-onap.onapatlassian.orgnet/wiki/display/DW/SO+Weekly+Meeting+2019-12-4)
• Make new BBs generic enough that they could be reused in other flows (request from Seshu)
• Service-Macro-Delete
  • Should we delete PNF resource from AAI on service deletion?
    
    • We plan to leave it. What orchestration status should it get? Inactive?