VMware Aria

 View Only
  • 1.  AA 8.18 - preventing deployment actions to run when condition is met

    Posted Sep 27, 2024 06:26 AM
    Edited by left_right Sep 27, 2024 06:26 AM

    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 Item
    event.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?



  • 2.  RE: AA 8.18 - preventing deployment actions to run when condition is met

    Posted Oct 03, 2024 03:22 PM

    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:




  • 3.  RE: AA 8.18 - preventing deployment actions to run when condition is met

    Posted Oct 04, 2024 10:08 AM

    "For the second try, the user can select "force" deletion, which you cannot prevent this way."

    This is the reason I resorted to a subscription initailly.

    However, I did not know you actually can create custom actions for deployments... This makes the whole ordeal trivial, thanks!




  • 4.  RE: AA 8.18 - preventing deployment actions to run when condition is met

    Posted 27 days ago
    Edited by left_right 27 days ago

    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-b179ef6137a6
    
    send: 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-revalidate
    
    header: Content-Length: 521
    
    header: Content-Type: application/json
    
    header: Date: Wed, 09 Oct 2024 08:50:09 GMT
    
    header: Expires: 0
    
    header: Pragma: no-cache
    
    header: Strict-Transport-Security: max-age=31536000 ; includeSubDomains
    
    header: Vary: Origin
    
    header: Vary: Access-Control-Request-Method
    
    header: Vary: Access-Control-Request-Headers
    
    header: X-Content-Type-Options: nosniff
    
    header: X-Frame-Options: DENY
    
    header: X-Xss-Protection: 0
    
    2024-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: None
    
    Finished 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-b179ef6137a6
    
    send: 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-revalidate
    
    header: Content-Length: 127
    
    header: Content-Type: application/json
    
    header: Date: Wed, 09 Oct 2024 08:48:54 GMT
    
    header: Expires: 0
    
    header: Pragma: no-cache
    
    header: Strict-Transport-Security: max-age=31536000 ; includeSubDomains
    
    header: Vary: Origin
    
    header: Vary: Access-Control-Request-Method
    
    header: Vary: Access-Control-Request-Headers
    
    header: X-Content-Type-Options: nosniff
    
    header: X-Frame-Options: DENY
    
    header: X-Xss-Protection: 0
    
    400 Client Error: Bad Request for url: https://my-aria-instance.local/deployment/api/deployments/9683e953-e411-4793-83f5-b179ef6137a6
    
    Finished 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?




  • 5.  RE: AA 8.18 - preventing deployment actions to run when condition is met

    Posted 27 days ago
    Edited by left_right 27 days ago

    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.




  • 6.  RE: AA 8.18 - preventing deployment actions to run when condition is met

    Posted 27 days ago

    Why are you defining your new day2 action on the resource, and not on deployment?




  • 7.  RE: AA 8.18 - preventing deployment actions to run when condition is met

    Posted 27 days ago

    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.




  • 8.  RE: AA 8.18 - preventing deployment actions to run when condition is met

    Posted 26 days ago
    Edited by xian 26 days ago

    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.

    vRA 8.12 introduced calling day2 actions from each other, see VMware Aria Automation: Nested OOTB Day 2 Actions with Resource Actions | VMware

    Unfortunately this is not allowed to delete actions, so you'll need to use the async trick.