SO tables aren’t updated as they should to run scale out use case. The following fixes should be applied:

a) Change action to scaleOut in northbound table (it was called something else that I can’t remember)

update northbound_request_ref_lookup set ACTION='scaleOut' where MACRO_ACTION='VFModule-ScaleOut';

b) Change resource type and target action in building_block_detail table

update building_block_detail set RESOURCE_TYPE='VF_MODULE', TARGET_ACTION='CUSTOM' where BUILDING_BLOCK_NAME='ConfigurationScaleOutBB';

update building_block_detail set RESOURCE_TYPE='VNF', TARGET_ACTION='CUSTOM' where BUILDING_BLOCK_NAME='GenericVnfHealthCheckBB';

For some reason, the original table had

c) Set target action to CUSTOM for different resource types and orchestration status in orchestration status table (NOTE: below is just an example, it should be done for ALL combinations of resource types and orchestration statuses)

insert into orchestration_status_state_transition_directive (RESOURCE_TYPE,ORCHESTRATION_STATUS,TARGET_ACTION,FLOW_DIRECTIVE) values ('VNF','ACTIVE','CUSTOM','CONTINUE');

insert into orchestration_status_state_transition_directive (RESOURCE_TYPE,ORCHESTRATION_STATUS,TARGET_ACTION,FLOW_DIRECTIVE) values ('VF_MODULE','ACTIVE','CUSTOM','CONTINUE');

orchestration_status_state_transition_directive has TARGET_TYPE=CUSTOM only for RESOURCE_TYPE=NO_VALIDATE.

The alternative to points 1.b and 1.c is to set RESOURCE_TYPE=NO_VALIDATE in building_block_detail table, but I’m not sure about the effect of that or what NO_VALIDATE means. If NO_VALIDATE skips AAI, then it’s not a viable option because we need to get the VNF IP from AAI.