stop deployment deletion when workflow fails

[jsauter42]

the final step in vm deployment is a post provisioning subscription to run a workflow and add an agent.

if it fails, the deployment is deleted and i am no longer able to troubleshoot why.  How do i make it stop? 

[WhiteForEver]

Hi,

Please try to add `preventDelete: true` like in an example below.

resources:
  Cloud_Machine_1:
    type: Cloud.Machine
    preventDelete: true
    properties:
      image: coreos
      flavor: small
      attachedDisks:
        - source: '${resource.Cloud_Volume_1.id}'
  Cloud_Volume_1:
    type: Cloud.Volume
    properties:
      capacityGb: 1

[sabom]

Set your subscription to "Blocking: yes" and the deplyoment will be not deleted in this case

[Sravan_k]

option-1 [Wrap the logic in your workflow with a try-catch block to handle errors]

try {
    // Your agent installation logic here
    System.log("Installing agent...");
    // Simulate success or failure
    if (Math.random() > 0.5) {
        throw "Simulated error";
    }
    System.log("Agent installed successfully.");
} catch (e) {
    System.warn("Error during agent installation: " + e);
    // Log the error instead of letting the workflow fail
}

[Sravan_k]

option-2: 

In vRA, post-provisioning subscriptions can be configured to not block the deployment lifecycle:

• Navigate to Infrastructure > Extensibility > Subscriptions in vRA.
• Edit the post-provisioning subscription.
• Uncheck the "Blocking" option. This ensures the deployment doesn’t rely on the success of the workflow.

[Greg Davis]

@Sravank's try-catch answer above is the best solution - set your subscription workflow up with error handling.

The key is for your workflow to reach a successful end state, regardless of whether the agent install succeeds or fails. Catch and log the error for troubleshooting. If you have Aria for Logs integration with Aria Auto you can set up a dashboard to capture failed agent install events.

Regards,

Greg D

[qc4vmware]

We handle this sort of situation by using custom properties as run controls.  If we need to troubleshoot something we'll modify the custom property so that a particular subscription does not throw an error.  This way you can easily sidestep the error being thrown for a single deployment or group of deployments without needing to modify any code.

[kwongheng22]

We are trying to do a similar thing too. We have various subscriptions post VM creation to configure the VM to our standard, like added certifications, registering to satellite or install packages for Windows OS. We want to setup a custom property such that when debug is true, any failure from those subscription will stop provisioning but will not trigger disposal process.  Modifying subscriptions or generic configuration in VRA 8 all the time is no go, we want to only debug a single VM, whilst allowing other VMs to continue provisioning failure or not. What would be the best practice to get this effect?