vRealize Automation 8 - Event Topics timeline

-

To a lot of vRealize Automation 6-7 Managers moving to vRealize Automation 8 is a rather large adaptation of new skillsets.

What we have currently been looking at is adapt the new Event Topic model.

And there is a lot of Event Topics to follow, but I still feel something is missing.

Full list of Event Topics documented @VMware Docs

Compute allocationYesIssued before the allocation of resourcenames and hostselections. Both of these properties can be modified at this stage.
Compute post provisionYesIssued after a resource was provisioned successfully.
Compute post removalYesissued after a compute resource was removed.
Compute provisionYesIssued before the resource is provisioned at the hypervisor layer.
Note:You can change the allocated IP address.
Compute removalYesIssued before the resource is removed.
Compute reservationYesIssued at the time of reservation.
Note:You can change the placement order.
Deployment action completedYesIssued after a deployment action is finished.
Deployment action requestedYesIssued before a deployment action is finished.

Mike @vbombarded has done some good footwork that helped us along.

Tho we felt the need to visualize the virtual machine deployment process in a timeline fashion.




After this work was done I was left wondering about where some vRA7 Event Topics went, and would we need them, so far I think we will need to investigate more about how to go about a few steps.

Steps we used in vRA7 that i haven't quite figured where to place contains along the lines of:
  • CloneWorkflow.CloneMachine.EVENT.OnCloneMacineComplete
    In this step we did some steps with machines like 
    • disk.enableUUID
    • ignition.config.data for OpenShift
    • picking up MAC address from network cards and reserve them in Microsoft DHCP

  • CustomizeOS.EVENT.OnCustomizeOS
    Perhaps we are old school and still use vSphere Customizations













Kommentarer

Legg inn en kommentar

Populære innlegg fra denne bloggen

vRA7 to vRA8 migration - Orchestrator

-
Steps to get up and running with vRO 8. Depending on your previous usage of vRO 7 this might the step that requires the most work when you are migrating to vRA8. Attribute Parameter Contains vCAC/vCACCAFE type! cafeHost|vCACCAFE:VCACHost| Switch to vRealize Automation 8 Types Input Parameter Contains vCAC/vCACCAFE type! subtenant|vCACCAFE:Subtenant Switch to vRealize Automation 8 Types Input Parameter Contains Payload Properties! payload|Properties Ensure the selected properties are supported by vRealize Automation 8 The first two will be quite common for everyone who has automated vRA7 using the vRA Plugins for vCAC and vCACCAFE the only working rewrite here is to move to the REST API and redo the work directly. The last one is also heavily used by everyone who relies on the Subscriptions both by pick up information in vRO and sending information back to vRA with " virtualmachineAddorUpdateProperties ". With just about 190 workflows to redo/rewrite or so i gues...
Les mer

vRealize Orchestrator - SSH Keys - Idea for how to easy manage multiple keys

-
Many are using SSH to run commands something similar to  var  passwordAuthentication = false; var password = ''; var session = new SSHSession(hostName, username, port); session.connectWithPasswordOrIdentity(passwordAuthentication, password, path); Where the path leads to the private key file for the connection. Storing several key files in the vRO filesystem could easily lead to forget it when moving to a new vRO or add a new vRO node. Also when moving forward with vRO 8 it's less of a good idea to add elements to the local filesystem as a manual step. My suggestion for a solution is to make use of the vRO resource element. Store your key file as a vRO resource element, using the following step of code can runtime make the key available for SSHSession. var tempDirectory = System.getTempDirectory(); filePath =  tempDirectory + "/" + keyfile.name; keyfile.writeContentToFile( filePath ); Send the private key file as a resource to the action or workflow and you will h...
Les mer

Possible pitfall - duplicate config_admin users - Using vRSLCM as deployment engine

-
Bilde
Some days ago as vRA 8.2 Patch 1 came along we decided to create a new test environment to see the upgrade process. It went rather smoothly as this is not the first environment to be deployed with vRSLCM. Few minutes of prepare vRSLCM and deployment went good, logging on to the new environment and then proceeded to install vRA 8.2 Patch 1.  https://docs.vmware.com/en/vRealize-Automation/8.2/rn/vRealize-Automation-82-releasenotes.html Now all went rather smoothly and we were please with the result. Sometime during the few last days also vIDM was patched to 3.3.3 https://docs.vmware.com/en/VMware-Workspace-ONE-Access/3.3/rn/VMware-Identity-Manager-333-Release-Notes.html And all of a sudden we lost access to our little test environment. As it was only there to test the upgrade patch 1, it was not a large issue, but strange never the less. In this test environment, we did not set up any other access roles, besides the default config_admin user. We could log in with it, but we had no ac...
Les mer