PNF PnP workflow migration to Building Blocks
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-2556: Migrate PNF PNP workflow to Building Blocks (CreateAndActivatePnfResource only)Closed
SO-2785: Migrate PNF PNP workflow to Building Blocks (Guilin enhancements)Closed
VID-693: VID support for PNF PnP: use Modern UIClosed
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-2640: AssignPnfBB - store model related PNF parameters in AAIClosed):
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
Currently implemented in CreateAndActivatePnfResource.bpmn
Support for config assign (ControllerExecutionBB, action: configAssign)
SO-2646: Support for PNF config assignClosed
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)
SO-2647: Support for PNF config deployClosed
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
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, scope: pnf)
ControllerExecutionBB (action: configDeploy, scope: pnf)
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 be 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
Generic controller BB working with PNFs
Update will be needed for BBInputSetup and WorkflowAction to support BBs which do not contain PNF in its name. Similarly as it was done for VNFs:
PNF PNP workflow integration with CDS
VID - required changes
VID-693: VID support for PNF PnP: use Modern UIClosed
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
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://lf-onap.atlassian.net/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?