VRA 8.2 ABX non blockable suscription is still blocking

[1fogenilac]

Hi everyone,

For testing purpose, i create an intentionally non working ABX flow (containing an action which call an input variable that do not exist).

As I add a subscription to the event 'compute allocation' with the disable parameter "block execution of event in topics" pointing to this ABS flow, Normally the execution error of the flow should not prevent the blueprint to create its resource (for instance a simple VM). But in reality the blueprint deployment fail as the ABX fail and no resource is created.

does anybody could find an explanation of such a comportment ?

thanks by advance

[emacintosh]

we do not use ABX, so I'm not familiar with how they may be used differently than vRO workflows, but does your ABX define an output to be sent back to vRA.  I think we have come across this before, where an Output is defined to be returned and when it isn't, a non-blocking subscription can still break a build.

Maybe if you could share the error you see, that might be helpful.  I think in the case above, it's typically something like Expected BEGIN_OBJECT but received String instead (or something to that effect).  In other words, vRA can't parse the output field(s) like it expects to.

[1fogenilac]

hi,

Thanks for your response emacintosh, but I am afraid that this explanation is not the right one. as you will see in the following logs the error received in the blueprint is really about abx execution error and not about payload miss-configuration.

nonetheless I still wonder why a normally asynchronous execution can interact with a deployment process. in theory we could imagine that abx action take a longer time to execute than the deployment without slowing it in any way.

here are the logs where we can see that the error is really from abx execution, if it can inspire for another explanation 😉

blueprints error :

Extensibility triggered task failure: Extensibility error received for topic compute.allocation.pre, eventId = 'bffb7fce-0f4c-33db-8a29-5db9ad545199': [10040] Service with ID: abx-mRT1Rb5BtzgRhvO5, RunnableID: 8a7480be726d6566017285df6c360258 and SubscriptionID: sub_1624371528565 failed with the following error: Cannot find property tagControl

ABX run error :

{  "errorMsg": "Action run '8a7480037a24a3c6017a3449bc4d0041' failed with state 'FAILED' and error message: Unknown property used in expression: ${tagControl == \"TagVM\"}",  "flowInputs": {    "tags": {},    "projectId": "ec5b3bbf-609f-4832-8f5a-5685d73c0d1e",    "requestId": "4ded9023-5c17-44bf-90d4-f7db11e72d57",    "__metadata": {      "orgId": "86d09d5a-7eac-42c6-baf9-4b3805e531d0",      "headers": {        "tokenId": "9s+GUui59NqWsIIHxksctTweH2k6/dnExHLipG3o6Mo=",        "blocking": "false",        "runnableId": "8a7480be726d6566017285df6c360258",        "runnableType": "extensibility.abx",        "uber-trace-id": "dae4a9008bf94c69889f9991efa6d92a:94b964c64b064571b575065079d33ae0:98c23703-a9bc-4e16-845f-e820295dacac:1",        "uberctx-org-id": "86d09d5a-7eac-42c6-baf9-4b3805e531d0",        "uberctx-user-id": "provisioning-C81GDFrQfTPdzz9i",        "eventTraceEntryId": "cda1ef2b-7472-48ca-b329-d8ce0f2e86d5",        "sampling-decision": "true",        "uberctx-parent-id": "98c23703-a9bc-4e16-845f-e820295dacac",        "provisioning-callback-uri": "/provisioning/config/extensibility-callbacks/47493ac7-4322-47b5-b12f-3336bee0aab9"      },      "targetId": "97094061-e596-49bd-afe9-8b8f2213ecd0",      "userName": "eng-ca-admin",      "eventType": "EVENT",      "timeStamp": 1624374863734,      "sourceType": "provisioning",      "targetType": "ComputeAllocationTaskState",      "eventTopicId": "compute.allocation.pre",      "correlationId": "7448a95c-afb7-42f3-82e4-0380b6b9298c--4ded9023-5c17-44bf-90d4-f7db11e72d57",      "sourceIdentity": "a4f41788-47e1-4663-a617-357b51d4b6a1",      "correlationType": "contextId"    },    "endpointId": "01b72a03-2598-4ca6-bcf8-35f3cb0f81c0",    "blueprintId": "028ed611-7aa5-42ad-94ae-33871079c46f",    "componentId": "ABX-VM",    "externalIds": [      "118f8e24-0292-4393-b7b3-ecdc91047d0f"    ],    "resourceIds": [      "1100bd95-bbdf-4e25-8a53-9decee11c576"    ],    "deploymentId": "7448a95c-afb7-42f3-82e4-0380b6b9298c",    "resourceNames": [      "Centos-ABX"    ],    "ebs.error.code": 10040,    "componentTypeId": "Cloud.vSphere.Machine",    "customProperties": {      "image": "VMW-CentOS",      "flavor": "VMW-Small",      "yamlTags": "{}",      "tagControl": "NoTag",      "newHostName": "Centos-ABX",      "customizationSpec": "Lin-Cust",      "resourceGroupName": "Lab-VMs"    },    "hostSelectionIds": [      "adecd2a9-55a1-4a88-b545-9b1ec3533291"    ],    "ebs.error.message": "Service with ID: abx-mRT1Rb5BtzgRhvO5, RunnableID: 8a7480be726d6566017285df6c360258 and SubscriptionID: sub_1624371528565 failed with the following error: Cannot find property tagControl"  }}

ABX history :

 Action run execution triggered from api

 Action has no preferred provider. Supported providers: aws, azure, on-prem

 Available on-prem endpoints in project: [embedded-ABX-onprem]

 Selected on-prem endpoint: embedded-ABX-onprem

 Available endpoints in project: [SA-vCSA-01/Datacenter:datacenter-1001]

 Supported endpoints in project: [SA-vCSA-01/Datacenter:datacenter-1001]

 Ignoring request endpoint type due to custom property: 'ignore.vm.endpoint'

 Available endpoints which comply with constraints: [SA-vCSA-01/Datacenter:datacenter-1001]

 Found 1 available endpoint(s) sorted by priority: [embedded-ABX-onprem]

 Endpoint chosen for action execution: embedded-ABX-onprem

Thanks for your responses

[jimmyvandermast]

As far as I understand, (non/)blocking is something else than failing.
An entire deployment is only finished as success when all underlying pieces are finished as success. So as long as one or more are running, the deployment is not finished, and so if one or more is failing the deployment fails.

Blocking or non-blocking only defines the flow between the pieces, not how the entire deployment ends.

[emacintosh]

Interesting, in our experience non-blocking subscriptions do not affect the overall deployment if they fail.  But maybe our specific scenarios are somehow exceptions or I'm misunderstanding the scenarios in which the deployment continues after a non-blocking subscription fails.

I wish that sort of info was spelled out more clearly in the documentation (or if I could find where it is if it is)

[1fogenilac · Accepted solution]

thanks for all your responses and suggestions,

here is our actual hypothesis :
- if your subscription point to a VRo workflow with non blocking parameter. the deployment process just trig the workflow as an asynchronous process. Despite, depending of the topic you subscribe, if it's a reply-able topic, you could get the result of the workflow execution in your final blueprint logs.
https://docs.vmware.com/en/vRealize-Automation/7.6/com.vmware.vra.prepare.use.doc/GUID-01B315E9-83E6...
(this link is for 7.6 version but explanation seems to still pertinent)

-if your subscription point to an ABX script, it seems to be the same thing.

-but if you point to an ABX flow, that's VRa itself which drive the car between each ABX script. and if one of the script smash the car it smash all the VRa process aka the blueprint deployment.

that's the explanation we will keep waiting for a better one 😉