Recently, I wanted to replace the self-signed certificate of Aria Automation using Aria Platform Lifecycle (formerly known as vRealize Lifecycle Manager). The customer has signed my CSR (created via Aria Platform Lifecycle) through their CA using the ECDSA (Elliptic Curve Digital Signature Algorithm) hashing algorithm in their intermediate certificates.
This ultimately fails with error LCMVRAVACONFIG90039 due to some arbitrary restrictions in the backend of Aria Automation.
Lately, I was developing an Extensibility Subscription workflow in Orchestrator, which queries the Aria Automation CMX REST API.
While it was perfectly running when being executed manually within Orchestrator, it fails when invoked from Aria Automation Service Broker as part of an Extensibility subscription (here Kubernetes Supervisor Namespace Post Provision).
The resulting error message was:
Catalog Item Deployment NS Test failed for Supervisor Namespace: Extensibility error for topic kubernetes.sv.namespace.provision.post: [10040] SubscriberID: vro-gateway-elsAsEMn7yjjbAGz, RunnableID: 587ed41a-a51b-4cdc-a10d-7c705a57db39 and SubscriptionID: sub_1695305241572 failed with the following error: Workflow run [fd626a0a-0386-4778-b2ad-8e7ffd5f5e9f] completed with error [Error in worker: HTTP error 500 - {"timestamp":"2023-08-20T16:26:45.991+0000","path":"/cmx/api/resources/supervisor-namespaces","status":500,"error":"Internal Server Error","message":"No orgId in token for vro-gateway-elsAsEMn7yjjbAGz","requestId":"f7763022-202212","@type":"java.lang.IllegalStateException"} (Dynamic Script Module name : executeRestCall#11) (Workflow:Kubernetes Supervisor Namespace Post Provision / Control WF (item4)#5)]This post describes how to add Tanzu supervisor clusters with Aria Automation Cloud Assembler for use in deployments and how to create namespaces in a supervisor cluster using a Cloud Template.
Supervisor clusters are customised Kubernetes clusters associated with vSphere. They expose Kubernetes APIs to end users, and they use ESXI as a platform for worker nodes rather than Linux. Supervisor namespaces facilitate access control to Kubernetes resources, because it is typically easier to apply policies to namespaces than to individual virtual machines. We can create multiple namespaces for each supervisor cluster.
Recently I was tasked to create some kind of instant auto-removal of failed Aria Automation deployments for a given Cloud template.
This can be achieved through leveraging a custom day 2 operation using the Aria Automation Deployment API request controller. For this particular use-case we execute the deployment resource “delete” action.
The required REST call for this resource action is: POST /deployment/api/requests/{requestId}
The JSON body must be specified as follows: { “actionId”: “Deployment.Delete”}
To execute this action every time a deployment fails, we use an Extensibility subscription to be automatically triggered if the status of the deployment is “FAILED” and the event type equals “CREATE_DEPLOYMENT”.
In this example we will use Aria Orchestrator to create the custom action.
Recently, I wanted to demonstrate Aria Automation’s multi-cloud capabilities. Therefore I wanted to use the official tutorial available on the VMware documentation web site as a basis (https://docs.vmware.com/en/vRealize-Automation/8.11/Using-and-Managing-Cloud-Assembly/GUID-6EC5AFE5-3C18-4F68-A7E3-82ADD4490002.html). In this tutorial we deploy the same cloud template to more than one cloud provider, in this case AWS and Microsoft Azure.
Setting up the infrastructure on AWS and Azure (labeled “part 1” in the official tutorial) works as described there (except that you have to select other image mappings), also the creation of the Aria Automation example project (labeled “part 2” in the official tutorial) works as described, but I had problems with the Automation Assembler templates to deploy the basic cloud template and the expanded cloud template (labeled “part 3” in the official tutorial).
Thus I’ve played around a bit and came up with two working cloud templates.
All your base are belong to us.