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
In Part 1 of this series we walked through how you can use the SovLabs Property Toolkit and Template Engine to configure vRealize Automation (vRA) for our environment input. In this second part of the series, we’re going to walk through setting up the Application and Compliance inputs for our particular use case. If you are starting to see smoke, don’t be alarmed. It’s just our Genie being let out of the lamp.
In Part 1, we determined that the required options for our Application input will be:
Determine the Outcome
In this scenario, the selection of the application will have a significant impact on the outcome. However, while we need to think about the application, we also need to look at the larger picture. What do I mean by “the bigger picture”? Well, once we figure out the desired outcome for each of these items, we need to think about how each item relates to the environment and the choices we made in Part 1.
What if the requester chooses WordPress as the application and Production as the environment? Alternatively, what if they choose Microsoft SQL and Development? Will the outcome of the application differ based on the environment to which it is being deployed?
Some things to consider:
Do the workload specs change based on the environment selection?
Do development, test, and production instances have the same CPU and Memory requirements?
Do any of the integrations change based on application and environment?
Do WordPress and Microsoft SQL have the same backup requirements?
Does this requirement change based on which environment the workload is being deployed to?
Whew the last few days have been full of new releases and VMware is not done yet. I’m not going to spoil anything but I will tell you that the release of vRealize Orchestrator 6.0.5 is not the last announcement you will be seeing from me. I anticipate some other exciting news next week. FOr now check out what’s new in vRO and stay tuned.
vRealize Orchestrator 6.0.5 is a patch release that introduces a number of improvements and bug fixes.
Enhanced workflow logging, including messages that mark the start and the end of the workflow run. In case of failure, the log captures the workflow ID, the request ID, and the exception.
Added ability to run a Debugger in the Orchestrator client when the request is generated by an external system, such as vRealize Automation, the vCenter Web Client, or a REST endpoint.
Introduced Spanish locale support for the Orchestrator plug-in for vSphere Web Client.
vRealize Orchestrator 6.0.5 also introduces Control Center, which delivers a more flexible configuring, monitoring, and troubleshooting experience. Control Center contains multiple built-in capabilities:
Many of you may have already seen the news, but I like to create a roll up to make it easy to see what’s been newly released. Yesterday Tuesday August 23rd 2016 VMware released a number of much awaited Management product updates. See below for a breakdown of the updates per product.
vRealize Automation 7.1
vRealize Automation 7.1 is optimized for growing clouds thanks to significant improvements in the automated installation experience.
vRealize Automation 7.1 continue simplifying the primarily and secondary setup process by adding ability to automate the setup process among similar deployments leveraging the new Silent Installer. Cloud Admins are now able to scale out existing vRealize deployment by adding more vRA components and manage them automatically though the new Command Line(CLI) interface.
vRA 7.1 release is also equipped with a brand new Migration tool which allows you to perform safe and sound side by side upgrade (migration) existing vRealize Automation systems 6.2.X to the latest and greatest release. During the migration process the source production environment remains intact which guarantees a minimum downtime of the production environment.
You might read the title and think to yourself ‘Why would I want to use vRO with Wink?” Well there are a number of reasons. I created this because being an automation specialist I thought it would be cool to automate my home. When I started down this path I got a wink hub, a smartthing hub, a philips hue hub, Chamberlain MyQ Garage Door Openers, Kwickset locks, Leviton & GE switches, Light Bulbs, a Smappee Energy, Water, & Gas Monitor, Nest Thermostat, Nest Protect, EcoBee, Ring doorbell, Canary, Harmony Hub, and a number of other hubs, devices, and sensors. As I started my project I realized on their own non of these products do a great job at automation. Sure you can control things via na app, but I want more than that. I don’t just want automation either, I want intelligent automation.
A simple example: I want my door locks to be locked after a defined period of time being unlocked. Well sure I can create a rule or robot that say lock door after x time, but that’s lacking intelligence. Maybe I want to lock the door only if it is closed. Non of these systems can do that. However with vRO I can create a workflow that locks the door and checks the door sensor to determine if it is opened or closed and if it’s closed, lock the door, if not check again in x period of time until it can be locked.
Another example: I park my vehicle in the garage. I like to remote start my vehicle in the winter to warm it up. I would sometimes forget to open my garage door then start my vehicle. With vRO I can mount a Nest Protect on my garage door right behind my exhaust and set a rule that if CO is detected, open the garage door. Alternatively I can use a OBDLink hooked up to my vehicle computer and through Dash determine if my vehicle is running and trigger garage door to open. You get the idea.
Over the weekend Roman, Grant, John and I released a significant update to the platypus project, which is essentially a very simple and elegant way to provide a Swagger based documentation of several VMware Products. This project started out by providing a quick way to consume the vRealize Automation 7 API, but it has grown a healthy set of legs.
vRA 7 introduced a number of new and very useful features such as unified blueprints, software components, event broker, and others. The event broker however has proven itself to be one of the most power new features we have seen in some time. How so you ask? Well if you have been working with vRA for any period of time you will remember the old way of triggering external workflow executions such as those run by vRO. If you have been using vRA for a really long time you will remember back before vRO when vRA wasn’t even vRA and run nothing but .Net workflows, but we won’t go back that far.
OK not too much on this one. If you wan to upgrade vRA to 7.0.1 and you want to use the plug-in in vRO 7.0 or 7.0.1 you will need this. That’s basically it. Just don’t forget you need this if you are upgrading and if you are doing a fresh install and are using a non embedded vRO server.
You will soon see the theme in all the releases that have been released today. Earlier I posted that vRA 7.0.1 was released and of course vRA and vRO are tightly tied so it seems obvious they would release an updated vRO as well. vRO 7.0.1 is a patch release. What’s the difference between and maintenance release and a patch release? Yeah I don’t know either. What I do know is it introduces some improvements, bug fixes, and resolved a very important issue that you may have seen with vRO. Issue CVE-2015-7547 “glibc getaddrinfo() stack-based buffer overflow”. For more information see the Resolved Issues.