You are right. I just remembered I had the same issue calling Deployment Update action via an EBS at the end of Deployment Create. I had to put the Deployment Update call into an asynchronous workflow, that would poll the deployment API and start updating the deployment when it was "ready".
So you need to do the same here, with workflows unfortunately: write a wrapper workflow that starts another async workflow, that tries to delete the deployment until your custom action (and wrapper workflow) finished. Also, if you want to disable the built-in Deployment Delete action, you have to use a service user to call the API, as the requestor will not have permission to run the built-in delete even via API.
Unfortunately this is not allowed to delete actions, so you'll need to use the async trick.
Original Message:
Sent: Oct 10, 2024 03:22 AM
From: left_right
Subject: AA 8.18 - preventing deployment actions to run when condition is met
This is a Deployment type action. The action itself gets triggered, but the REST query that is supposed to delete the deplyoment ends with a HTTP 400:
The action takes the deployment id and initiates a DELETE api call.
I suspect that the issue here is, that when the action is triggered, it starts a lifecycle opration on the deployment and if during that time a deployment delete is triggered, it automatically fails since the deployment resource is "busy".
If I change the deployment DELETE request in the action to a GET, it runs thourgh fine.
Original Message:
Sent: Oct 09, 2024 01:23 PM
From: xian
Subject: AA 8.18 - preventing deployment actions to run when condition is met
Why are you defining your new day2 action on the resource, and not on deployment?
Original Message:
Sent: Oct 09, 2024 06:18 AM
From: left_right
Subject: AA 8.18 - preventing deployment actions to run when condition is met
EDIT:
I just noticed a discrepancy between running an action test, which works, and running the custom resource action, which fails.
The discrepancy can be found in the request itself. When the script is ran directly or as test, the requests starts with:
Oct 9, 2024, 9:24:04 AM
REQUEST_IN_PROGRESS
DELETES Custom_my_resource of type Custom.my_resource
and follows directly into the custo mresoruce delete action:
Oct 9, 2024, 9:24:10 AM
DELETE_IN_PROGRESS
Custom.my_resource
Custom_my_resource
This works fine.
When the requst is initiated using the resource action, it starts with:
Oct 9, 2024, 9:52:13 AM
INITIALIZATION_IN_PROGRESS
Oct 9, 2024, 9:52:13 AM
REQUEST_IN_PROGRESS
ACTIONS my-deployment of type Deployment
And almost immedietally follows with:
Action run failed with the following error: "400 Client Error: Bad Request for url: "
Oct 9, 2024, 9:52:17 AM
ACTION_IN_PROGRESS
Deployment
my-deployment
Oct 9, 2024, 9:52:20 AM
ACTION_FAILED
Deployment
my-deployment
So in the failed run the delete request immedietally fails, without triggering any resource actions.
EDIT2:
I guess the error is cause by trying to delete a deployment, while this deployment itself is being updated by an action, so some sort of circular dependency is caused.
Original Message:
Sent: Oct 09, 2024 05:12 AM
From: left_right
Subject: AA 8.18 - preventing deployment actions to run when condition is met
I went with the "resource action route" and have written a small ABX action in python, that basically does nothing more but executing a DELETE request on the deployment url.
The action runs fine when run locally in Python, it also runs well when the action is ran directly using "Test".
What I cannot explain and am currently pulling my hair out is, that when I use the script in a custom resource action, to delete the Deplyoment, I get an error 400:
"400 Client Error: Bad Request for url: https://my-aria-instance.local/deployment/api/deployments/9683e953-e411-4793-83f5-b179ef6137a6"
The relevant code block is below, it is a function within a class, with enabled http client debugging:
def api_delete(self, path: str) -> dict: # Enable debugging import http.client as http_client http_client.HTTPConnection.debuglevel = 1 logging.basicConfig() logging.getLogger().setLevel(logging.DEBUG) requests_log = logging.getLogger("requests.packages.urllib3") requests_log.setLevel(logging.DEBUG) requests_log.propagate = True # Perform the DELETE request with paramets logger.debug(f"DELETE query url: {self.url}{path}") response = requests.delete( f"{self.url}{path}", headers=self.header, verify=False ) response.raise_for_status() logger.debug(f"Response Headers: {response.headers}") if response.status_code == 204 or 201: return None
The wall I got to during troubleshooting is, that in both cases: when ran directly (locally) or as Test in Assembler, and ran as a resource action on the deployment, the http client provides the same exact output:
SUCCESSFUL request:2024-10-09 08:50:09,694 - vra_class - DEBUG - DELETE query url: https://my-aria-instance.local/deployment/api/deployments/9683e953-e411-4793-83f5-b179ef6137a6send: b'CONNECT my-aria-instance.local:443 HTTP/1.0\r\n\r\n'send: b'DELETE /deployment/api/deployments/9683e953-e411-4793-83f5-b179ef6137a6 HTTP/1.1\r\nHost: my-aria-instance.local\r\nUser-Agent: python-requests/2.31.0\r\nAccept-Encoding: gzip, deflate\r\nAccept: */*\r\nConnection: keep-alive\r\nAuthorization: Bearer [TOKEN HIDDEN]\r\nContent-Length: 0\r\n\r\n'reply: 'HTTP/1.1 200 OK\r\n'header: Cache-Control: no-cache, no-store, max-age=0, must-revalidateheader: Content-Length: 521header: Content-Type: application/jsonheader: Date: Wed, 09 Oct 2024 08:50:09 GMTheader: Expires: 0header: Pragma: no-cacheheader: Strict-Transport-Security: max-age=31536000 ; includeSubDomainsheader: Vary: Originheader: Vary: Access-Control-Request-Methodheader: Vary: Access-Control-Request-Headersheader: X-Content-Type-Options: nosniffheader: X-Frame-Options: DENYheader: X-Xss-Protection: 02024-10-09 08:50:09,969 - vra_class - DEBUG - Response Headers: {'Cache-Control': 'no-cache, no-store, max-age=0, must-revalidate', 'Content-Length': '521', 'Content-Type': 'application/json', 'Date': 'Wed, 09 Oct 2024 08:50:09 GMT', 'Expires': '0', 'Pragma': 'no-cache', 'Strict-Transport-Security': 'max-age=31536000 ; includeSubDomains', 'Vary': 'Origin, Access-Control-Request-Method, Access-Control-Request-Headers', 'X-Content-Type-Options': 'nosniff', 'X-Frame-Options': 'DENY', 'X-Xss-Protection': '0'}2024-10-09 08:50:09,969 - delete_deployment - INFO - Deleted deployment with id: 9683e953-e411-4793-83f5-b179ef6137a6, return code: NoneFinished running action code.Exiting python process.Python process exited.
FAILED request:2024-10-09 08:48:54,223 - vra_class - DEBUG - DELETE query url: https://my-aria-instance.local/deployment/api/deployments/9683e953-e411-4793-83f5-b179ef6137a6send: b'CONNECT my-aria-instance.local:443 HTTP/1.0\r\n\r\n'send: b'DELETE /deployment/api/deployments/9683e953-e411-4793-83f5-b179ef6137a6 HTTP/1.1\r\nHost: my-aria-instance.local\r\nUser-Agent: python-requests/2.31.0\r\nAccept-Encoding: gzip, deflate\r\nAccept: */*\r\nConnection: keep-alive\r\nAuthorization: Bearer [TOKEN HIDDEN]\r\nContent-Length: 0\r\n\r\n'reply: 'HTTP/1.1 400 Bad Request\r\n'header: Cache-Control: no-cache, no-store, max-age=0, must-revalidateheader: Content-Length: 127header: Content-Type: application/jsonheader: Date: Wed, 09 Oct 2024 08:48:54 GMTheader: Expires: 0header: Pragma: no-cacheheader: Strict-Transport-Security: max-age=31536000 ; includeSubDomainsheader: Vary: Originheader: Vary: Access-Control-Request-Methodheader: Vary: Access-Control-Request-Headersheader: X-Content-Type-Options: nosniffheader: X-Frame-Options: DENYheader: X-Xss-Protection: 0400 Client Error: Bad Request for url: https://my-aria-instance.local/deployment/api/deployments/9683e953-e411-4793-83f5-b179ef6137a6Finished running action code.Exiting python process.
I even checked with comparing the logging side by side, to be sure. Both requests are identical, same url, token etc. One of those, executed using the resource action, fails consistently with HTTP 400.
Is it possible, that replacing the default Delete action on a deployment by a custom resource action is somehow prohibited?
Original Message:
Sent: Oct 03, 2024 03:22 PM
From: xian
Subject: AA 8.18 - preventing deployment actions to run when condition is met
There is a workflow associated with deleting your CRT. Why don't you fail this workflow if the condition is met?
For the second try, the user can select "force" deletion, which you cannot prevent this way. You have to write your custom deployment delete action and disable the built-in.
You can create custom deployment actions, just select your custom WF:
Original Message:
Sent: Sep 27, 2024 06:25 AM
From: left_right
Subject: AA 8.18 - preventing deployment actions to run when condition is met
For one of my custom resource based deployments, I need to prevent deletion of the provisioned deployment (by the Delete action) when a specific condition is met.
The specific condition is, that a "flag_property" on the custom resource has to be == 0, otherwise the Deplyoment Delete will end with an error.
If "flag_property" ist > 0, the Deployment Deletion request should get cancelled, or jsut not started at all.
In an ideal case, if the condition is True, the Deletion request should fail right after selecting the Delete Action. However, the Delete Action is one of the actions, where you get no interaction window, so it is not possible to exctract the needed information before pressing the "REQUEST" button; Delete is is executed without confirmation.
While this is unfortunate, I have created a workaround, where the value of the "flag_property" on the deployment resource is checked, and if the condition is met, the request gets cancelled.
This is done by a EBS subscription, configured with the "Deployment Requested" event topic. I've set a condition here to only run it for this specific template and action:
(event.data.blueprintId == "8ef7f34f-a981-4460-a1a2-89af2f03b200" && // check Blueprint; does not trigger on deletion, bug?event.data.eventType == "DESTROY_DEPLOYMENT") ||(event.data.catalogItemId == "8b2cea49-6cc6-3e5c-8c29-b55b71ca1d92" && // check Catalog Itemevent.data.eventType == "DESTROY_DEPLOYMENT")
The subscription triggers an ABX action, where the parameter value is checked and the request cancelled, should the condition be met. Here is a code snippet:
# Check if resoruce has flag set dep_resource = vra_rest.get_deployment_resources(inputs["deploymentId"]) # Grab deployment resource cancel_req = True if len(dep_resource[0]["properties"]["flag_property"]) > 0 else False # Check value of flag property # Cancel request if condition is met if cancel_req: dep_request = vra_rest.get_requests_of_deployment(inputs["deploymentId"]) # Grab deployment requests req = dep_req["content"][0] # Grab latest request (assuming this is the Delete request) vra_rest.cancel_request(req["id"]) # Cancel request logger.info("Flag property > 0, cancelled delete request {}".format(req["id"])) return {"canceled_request_status" : req["status"]}
This workaround is not elegant, and for it to trigger a user has to have already executed the Delete action. Afterwards the condtion is checked.
The action often fails with an error 404, because the resource already gets deleted jsut before the subscription runs. I cannot find a way to prevent it.
I have also thought about writing my owne "Delete" action, but there does not seem to be a way to created custom Deplyoment actions in Aria Automation... bummer.
Is there maybe a more elegant solution for this problem?