Procedure to address descrepancies between Heat stack template and third party Orchestration template

Products

• VMware Integrated OpenStack

Issue/Introduction

• Scale in and scale out operations fail to instantiate new resources with one of the following error messages

  • "UPDATE_FAILED"

  • "CREATE_FAILED: Resource CREATE failed"

  • "StackValidationFailed"

  • "Task failed: Scale out operation failed"


• Heat stack-update errors indicate an invalid resource type or unauthorized template modification.
• Comparing the Heat Stack template parameters in VIO with the parameters in with the application vendors orchestration template shows that there is a mismatch in the resource type.

• In the below example : Heat stack template in VIO defines the resource using an environment file alias (custom resource type):

     
     type: DSC::Scaling::Server to an external nested YAML file definition

• But, third party CSAR template parameter defines the exact same resource using a direct relative file path:             

         type: Resources/HotFiles/<########_CUSTOM_SCALING_FILE>.yaml 

Environment

• VIO 7.3

Cause

• There is a resource type referencing mismatch in the Openstack Heat stack template and third party Orchestrator YAML templates.
• OpenStack Heat requires strict structural consistency between the deployed stack and the orchestration template used by the application for subsequent update or scale-out operations.
• When the parameters for the resource type do not match exactly, the Heat engine interprets this as an invalid definition for the existing resource or an unauthorized stack update, causing the scale-out workflow to abort.

Resolution

 

1. Validate the OpenStack Heat template against the application orchestration template and identify if there are any resource type parameters with mismatches.

2. Modify the resource type parameter in Orchestration template (VNFM / CSAR) used by the application  to match with the resource type parameter in the VIO Heat stack template. 

3. Modifying Heat templates from VIO on live VNF workloads is not supported and may introduce severe data layer discrepancies between the VIO running  state and the external orchestrator

4. If the the parameters in the third party Orchestration template are hardcoded, edit the Heat stack template and perform a dry run in a non-production or test environment first to validate there is no impact using the below command

  # openstack stack update --dry-run --template <updated_blueprint_file.yaml> <target_stack_name>

5. Post-validation, after confirming there is no destructive disruption to the application, execute the template update:

  # openstack stack update --template <updated_blueprint_file.yaml> <target_stack_name>