In Part 1 of this two-part series on the vRealize Automation Migration Assessment Tool, we looked at the vRA8 migration tool to see how it might help you plan your migration from vRA7 to vRA8. In this article, we are going to look at what it will take to migrate your custom workflows from vRA7 to vRA8. To start, we will explore what a custom workflow looks like to day in vRA7.
{{cta(’58c71586-bbe1-4867-bf96-b66ee58b4caf’,’justifycenter’)}}
vRA7 Workflow Components
In vRA7, there are a number of components that come together to make the magic happen. Each component plays a vital role in how you design, build, and invoke your customizations.
Event Broker
The event broker was introduced in vRA7 to make it easier to trigger the workflow stubs that existed within the IaaS server. These stubs were always there, but only a handful were accessible and they were not easy to configure. The Event Broker also introduced a more granular way to decide when a workflow should or should not be executed. Although the event broker has dozens of events you could subscribe to the following were the most commonly used:
- Machine Requested
- Building Machine
- Machine Provisioned
- Machine Activated
- Machine Destroyed
Many of these states included a pre and a post execution allowing you to decide if you wanted to execute your workflow before of after vRA’s execution of that state. These states that are the core of vRA7 extensibility no longer exist in vRA8. vRA8 is a completely new platform, written from the ground up, and no longer includes the IaaS host that controlled all of these states in vRA7.
vRA8 has introduced new event subscription topics that — in the long term — could be very welcomed; however, in the short term, it will mean reworking all your existing workflow customizations. These new event subscription topics are listed below.
- Deployment Level
- Deployment Requested
- Compute Reservation
- Compute Allocation
- Network Configure
- Deployment Completed
- Network Level
- Deployment Resource Requested
- Deployment Resource Completed
- Machine Level
- Deployment Resource Requested
- Compute Provision
- Compute Post Provision
- Deployment Resource Complete
As you can see, this change is significant to the event subscriptions as well as the overall lifecycle that a virtual machine goes through when it is requested. This change alone is not so bad, right? Simply setup new subscriptions to execute your existing vRealize Orchestrator (vRO) workflows and all is good, right? Well, not exactly. For more information on the new event states in vRA8 check out vRealize Automation 8 Extensibility Event Topic Order of Operations by Mike Bombard.
Event Schemas
In vRealize Automation, all of the Events that are part of the Event Broker have a schema. Looking at the schema for LifeCycle Events in vRA7, you will notice that it includes items like machine, lifecyclestate, properties, and virtualmachineAddorUpdateProperties. These items are all included in what is commonly known as the Payload. The payload is sent to vRO and you can then reference information about the request. You can access all the custom properties associated with the request under machine.properties.
All workflows built using vRA7 use this payload to take in information such as properties and also write back updated information using the virtualMachineAddorUpdateProeprties to impact the outcome of the request. The payload is sent by vRA. Then, you extract the information you are looking for using the schema below. That data is then used throughout your workflow.
In vRA8, this payload has changed significantly. In fact, it has changed so much that it’s not even called payload anymore. It’s new name is “Inputs”. Not only has the name changed, but what is included has changed as well. If we start to look at the machine.properties item in vRA7, we know it included all the custom properties associated with the request, including inputs to blueprint properties, business group properties, property groups, reservations, compute resources, and endpoint properties. vRA8 uses a different methodology and has very limited support for properties. These similar constructs now use tags.
This change is a major shift in the architecture. Most workflows are built around these concepts and being able to acquire the needed information from the properties being defined in the appropriate locations. Because of this change, workflows built to run on vRA7 will not function on vRA8. Below is the Schema from the “Compute Provision” state in vRA8. Notice the differences between this vRA8 Schema (below) and the vRA7 Schema (above).
The vRA plugin for vRO
If you are building vRO workflows for vRA, you are most likely using the vRA plugin for vRO. The plugin allows you to create endpoints for both the IaaS host as well as the Cafe host to be used in your workflows. The vRA plugin for vRO also has a number of prebuilt actions and workflows that you can use to make your life easier. Easier if your workflows are built for vRA7.x because no plugin exists in vRA8 today. If VMware were to ever come out with a new plugin for vRA8, it would be vastly different than the current plugin and wouldn’t help much in the way of migration.
Today, if you want to interact with vRA8, you will need to use the vRO Rest plugin and do so through the Rest API.
There Is Another Option
I’m sure many of you were hoping that workflows that you build, are building, or have built for use in vRA7 would be somewhat transferable to vRA8. Unfortunately, it doesn’t look like it will be that easy. To salvage your current workflows, you will need to consider the following questions.
Does your vRA7 workflow…
- rely on properties from vRA7 constructs to make decisions?
- rely on the vRA7 payload the schema associated with it?
- rely on the vRA plugin for vRO?
If you answered yes to even one of these questions, then you will have to rework your workflows for use in vRA8. If you answered yes to more than one of the questions, then you will need to start from the ground up.
Or will you?!?
There is another option. I have been helping many vRA customers migrate away from their customizations on vRA7 to the modules produced by SovLabs in preparation for migrating to vRA8. Whether you are solely using lifecycle workflows, or using XaaS Blueprints in vRA to meet your businesses needs, we can help. Migrating your customizations to policy-driven software (Yes, SovLabs software…shameless plug) now will allow you to avoid having to rewrite code. And, migrating your SovLabs configurations from vRA7 to vRA8 is seamless.
Whatever you choose, don’t wait until the last minute to start planning.
{{cta(’58c71586-bbe1-4867-bf96-b66ee58b4caf’,’justifycenter’)}}
