The OneFuse Property Toolkit is the Swiss army knife of the OneFuse Platform
The OneFuse Property Toolkit is the Swiss army knife of the OneFuse Platform. It can be used in many different ways to assist you in meeting your automation needs. It can be used to simplify configurations, define business logic as configuration, build simple logic or tackle the most complex problems. In its simplest form its meta-data that can be used as a reference offering simple name value pairs that can be used as a reference for decision making. In its most powerful form it can contain logic, decision trees, platform abstractions, and much more.
SovLabs has been busy developing a tool that is intended to analyse your vRealize Automation 7 environment and provide helpful feedback on areas where you can optimize. The tool collects data on dozens of vRealize Automation 7 constructs such as number of blueprints, types of blueprints, number of business groups, network profiles, reservations, etc. and looks for key indicators to see if there is room for optimization. It also goes a step further and looks for items that could create challenges when customers are looking to migrate to vRealize Automation 8.
The goal here is to optimize your vRealize Automation 7 environments before adopting vRealize Automation 8. We all acknowledge that vRealize Automation 7 will be around for at least another 18-24 months – if not longer. Even if you are making the move to vRealize Automation 8 today, you will likely still be maintaining your vRealize Automation 7 environments alongside for some time to come. By optimizing your vRealize Automation 7 environments you will be reducing the maintenance overhead required for your current environment while also making it easier to migrate and adopt your solution on vRealize Automation 8. The more aligned the two instances are, the simpler it will be to maintain both environments side by side.
The best part is it’s free, yes that is correct I said free. You simply register at https://www.sovlabs.com/vrealize-automation-optimization-assessment and, once registered, a member of the SovLabs team will reach out to assist you with the data collection. The data is done using a vRO workflow that produces a JSON output. The data that is collected is non-identifying or sensitive so you don’t have to worry. The data collected is also presented in plain text so you can review the data before you send it back to Sovlabs for analysis. If you have more than one vRealize Automation 7 environment you can run the collector for each environment and then zip all the files together for upload.
Once data collection is complete, you then head over to https://optimize.sovlabs.com/ and upload your results file. From there the folks at SovLabs will take the result, run it through their analysis tool and produce a report detailing all the areas where you can optimize your vRealize Automation 7 environment(s). A SovLabs technical representative will reach out to schedule a time to go over the report and send you a copy. Whether you are looking to Optimize your vRealize Automation 7 environment or gain some insight into your pending vRealize Automation 8 migration, the SovLabs Optimization and Upgrade Assessment provides great information and insights to help plan and prepare your automation path.
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.
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:
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.
Action Based Extensibility (ABX), vRealize Orchestrator and Extensibility
ABX is the new extensibility offering packaged with vRA8 (in addition to vRealize Orchestrator) that uses a FaaS provider (AWS, Azure and On Prem offered today) to provide extensibility for the new platform. As someone who has spent countless hours working with vRO, ABX is probably one of the more intriguing announcements surrounding vRA8.
One of the things that I am impressed with right out of the gate is that the ABX action runs show you the code that was used as well as the payload that was passed for use in the action. In fact, both Orchestrator and ABX runs can be monitored directly from the Cloud Assembly UI. No more having to log in to a separate interface to see what is happening with your extensibility. This methodology makes troubleshooting much more accessible.
vRealize Automation veterans may still remember the migrations from vRA 5.x to 6.x and 6.x to 7.x. However, for many enterprises utilizing vRealize Automation, the migration from vRA 7.x to vRA 8.x will be your first major vRA migration. In an ideal world these migrations would only take a few clicks of the mouse. Migrating from vRA7.x to vRA8.x is going to be a lot like switching banks. Trying to figure out all the services that have your bank card on file for automatic billing and moving over automatic bill payments is tedious and time consuming. Which payments are monthly, quarterly, annually, and for how much? Wouldn’t it be nice if there were a simple tool to identify and update all the services that you have on auto-pay?
vRealize Automation is a lot like that. Whether it’s frequently deployed common workloads, special purpose blueprints that are used a few times a month, quarterly, or a handful or fewer times a year, or software customizations specific to vRA, you have to identify everything that will require hand-holding when you begin the migration from vRA7 to vRA8. The good news is that, unlike your bank, VMware does offer a migration assessment tool to help you determine if your blueprints are ready to be migrated from vRA7 to vRA8. As of this writing, we have not yet learned if the migration assessment tool will determine if your customizations and workloads are ready for migration.
Integrating Red Hat Ansible Tower with VMware vRealize Automation is a very popular enterprise automation solution. SovLabs has several excellent integrations that can help you accomplish and scale your integration of these two powerful cloud automation tools. This article is the first in a series of four articles covering the integration of Red Hat Ansible Tower with VMware vRealize Automation, based primarily on the content and discussion from our webinar with Red Hat Ansible on May 22.
Requesting a vRealize Automation deployment from Ansible. How, and why you would want to do it.
The SovLabs Ansible Tower Module for vRealize Automation with Static Inventory
The SovLabs Ansible Tower Module for vRealize Automation with Dynamic Inventory
The SovLabs Ansible Tower Plug-in for vRealize Automation CM Framework
Requesting a vRealize Automation deployment from Ansible
With Ansible Tower quickly growing in popularity, many developers and system administrators want to be able to utilize Ansible Tower to deploy infrastructure. This type of deployment is the subject of many debates within enterprise organizations, especially those with cloud teams trying to develop standards while enforcing policy and governance across organizations.
The good news is that organizations no longer have to choose between solutions. If you want to use Ansible to develop standards while enforcing policy and governance across organizations, now you can. Using the solution below you can request workloads from Ansible facilitated by vRA to enforce the desired standards and governance policies. Let’s take a look at how it works.
If I had a dollar for every time someone asked me, “Is there a place to define global properties in vRA?” throughout my career, I probably could have retired by now. The unfortunate answer to this question has always been “it does not”, but there is a way to apply properties to every request. Keep reading.
The Old Way
The old way to define global properties in vRA was to add the properties you wanted applied globally to each and every endpoint you had configured in vRA. So, if you had 25 endpoints and 20 properties you ended up have to enter 500 properties and 500 values. This method leads to inevitable typos, finger fatigue, and management overhead every time you need to update a value for any one of those properties or add a new property.
SovLabs has released it’s latest version of it’s vRealize Automation plugin version 2019.8.0. Among other key updated it is Certified for vRealize Automation 7.6 as well as ServiceNow Madrid. Below is the full list of updates available in this release:
Certified for vRA 7.6!
A new SovLabs 2019.x license key is needed in order to use the SovLabs 2019.x Plug-in
Ever wish you were able to set more than one value from a single vRealize Automation (vRA) request input? Have you ever wished you could make some aspects of vRA more dynamic and flexible? Wish you could simplify the vRA request form? In this article I’m going to let the genie out of the bottle. All your wishes are about to come true. But before we summon our genie, let’s first dive into what it is that we are going to be wishing for. My wish is to have a simple vRA request page with only three inputs that can drive the outcome of every aspect of my request. Sounds too good to be true doesn’t it? We will find out soon enough.
Determine the needed Inputs
Determining what our inputs are going to be. For my scenario I need to the following three inputs:
The Environment (Production, Development, or Test)
The Application (WordPress or Microsoft SQL)
Compliance Needs (SOX or Non-SOX)
In my example, these are the only three items I need to know from the requester to build a server in my environment. The remaining info I can gather from the business group they belong to, what resources the workload is placed on, etc. I know every environment is different and many will require more than three inputs. Once you have read this entire 3-Part series, you will realize the number of inputs doesn’t matter. It’s how we use them that’s key.
Determine the outcome
What outcomes do we need to drive based on these inputs? Or, how will these help determine the outcome of the overall deployment? Will they influence items such as the machine hostname, Active Directory OU placement, vCenter Folder placement, vSphere tagging, application installation, etc?
About the Free Custom Hostname Extension for vRealize Automation
Here at SovLabs we are always helping our audience make the decision to either “build” or “buy”, when it comes to VMware automation solutions. Recently, we have been involved in some discussions about the free Infoblox plugin for vRealize Automation. Specifically,these discussions are around how the free Infoblox plugin for vRealize Automation handles custom host naming. That discussion prompted us to consider all such customizations and the support required when when they are integrated with vRealize Automation.
Custom Automation Considerations
There are a few issues at play here, including:
How do the different components of your solution work together?
Was it designed wholistically or were pieces added on as you needed them?
Did one source develop all of the components, or are they pulled piecemeal from multiple places?
If one source did all of the development – are they still available?
Who is supporting the development work going forward?