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.
By PNF PNP workflow we understand 2 BPMNs:
- CreateAndActivatePnfResource
- ConfigurePnfResource
Both included in CreateVcpeResCustService_simplified BPMN
JIRA
- SO-2556Getting issue details... STATUS
- SO-2785Getting issue details... STATUS
Involved parties
- Lukasz Grech, Damian Nowak - PNF PNP workflow migration to BBs
- Oskar Malm - ConfigurePnfResource.bpmn (previous, non-BB implementation)
- Henry Xie - SO-CDS integration, new API for calling CDS from SO
- Yuriy Malakov - CDS, SO-CDS integration
- Rahul Tyagi - PNF SW upgrade, SO-CDS integration
Proposed building blocks
AssignPnfBB
- Responsibility:
- Creates PNF entry in AAI (with PNF name chosen by user)
- Additionally stores PNF model-related parameters in AAI (
-
SO-2640Getting issue details...
STATUS
):
- model-customization-id
- model-invariant-id
- model-version-id
- Makes a link in AAI between Service entry and PNF entry
- Sets PNF orchestration status in AAI to Assigned
- Currently implemented in CreateAndActivatePnfResource.bpmn
WaitForPnfReadyBB
- 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
- Waits for "PNF ready" event sent from PRH to DMaaP
- Currently implemented in CreateAndActivatePnfResource.bpmn
ControllerExecutionBB (action: configAssign)
- SO-2646Getting issue details... STATUS
- Responsibility:
- Runs config assign via CDS
- Currently implemented in ConfigurePnfResource.bpmn
- Things to consider:
- New approach to calling CDS/controllers - ControllerExecutionBB/actor in SDC model (Henry Xie, see https://wiki.onap.org/display/DW/SO+Weekly+Meeting+2019-12-4)
- SkipPostInstantiationConfiguration should be taken into account
ControllerExecutionBB (action: configDeploy)
- SO-2647Getting issue details... STATUS
- Responsibility:
- Runs config deploy via CDS
- Currently implemented in ConfigurePnfResource.bpmn
- Things to consider:
- New approach to calling CDS/controllers - ControllerExecutionBB/actor in SDC model (Henry Xie, see https://wiki.onap.org/display/DW/SO+Weekly+Meeting+2019-12-4)
- SkipPostInstantiationConfiguration should be taken into account
ActivatePnfBB
- Responsibility:
- Sets PNF orchestration status in AAI as Active
Sequence in Service-Macro-Create flow
- AssignServiceInstanceBB
- CreateNetworkCollectionBB
- AssignNetworkBB
- AssignVnfBB
- AssignVolumeGroupBB
- AssignVfModuleBB
- AssignPnfBB
- WaitForPnfReadyBB
- ControllerExecutionBB (action: configAssign)
- ControllerExecutionBB (action: configDeploy)
- ActivatePnfBB
- ConfigAssignVnfBB
- CreateNetworkBB
- ActivateNetworkBB
- CreateVolumeGroupBB
- ActivateVolumeGroupBB
- CreateVfModuleBB
- ActivateVfModuleBB
- ConfigDeployVnfBB
- ActivateVnfBB
- ActivateNetworkCollectionBB
- ActivateServiceInstanceBB
SO - required changes
API handler
GR API
SO API currently doesn't allow to send PNF information in user data section.
Here's the proposed request which includes PNFs:
Building Block framework
Service decomposition (Retrieve BB Execution List)
- PNFs should recognized in service model and proper BBs should be assigned for execution.
GeneralBuildingBlock initialization (BB Input Setup)
- PNF resources should be properly initialized in GeneralBuildingBlock→ServiceInstance
PNF PNP workflow integration with CDS
VID - required changes
Updates for service macro instantiation:
- "unlock" modern UI when for PNFs
- allow to assign PNF instance name (will be used instead of pnfCorrelationId)
- ensure that proper request is sent to SO
Other considerations
- 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
- Currently those are:
- How to include new BBs in Service-Macro-Create flow?
- Where to put new BBs in the flow sequence?
- Service decomposition in WorkflowActionBB may not unserstand PNFs (Retrieve BB Execution List)
- Service decompositioon should handle SkipPostInstantiationConfiguration
- PNF orchestration status changes in AAI - which states should be assigned in which steps of the workflow
- Should we have ActivatePnfBB?
- 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://wiki.onap.org/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?
- Should we delete PNF resource from AAI on service deletion?