Harness the Power of vRA with the SovLabs Property Toolkit and Template Engine – Part 2

{% raw %}

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:

• WordPress
• Microsoft SQL0

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:

1. Do the workload specs change based on the environment selection?
2. Do development, test, and production instances have the same CPU and Memory requirements?
3. Do any of the integrations change based on application and environment?  
4. Do WordPress and Microsoft SQL have the same backup requirements?
1. Does this requirement change based on which environment the workload is being deployed to?
5. What else could affect the outcome?

Determine the Impact

Much like the environment input, we need to figure out what impacts the application input will have on our request.  Now that we have two inputs, we also have to consider how they will work together to determine the impact they will have together.

Let’s take a look at our two options for the application input and see what impact they will have on the request:

Table 1 

While it is possible to present the CPU and memory as seperate inputs, in this example, I’ve chosen to dynamically determine their values.  This approach allows us to determine the appropriate resources based on what has been defined by the organization. Also, we can ensure enforcement of items such as setting cores rather than the number of CPUs where applications are licensed by socket.

Now we can limit unnecessary inputs form the requester. Does the requester really need to chose the operating system, version, cpu, memory, and related items?  Probably not.

Building it Out

Similar to what we demonstrated in Part 1, we’re now going to look at two options.  These two options are not the only two options by which we can accomplish the scenario with the SovLabs plug-in; however, these are two compelling ways to achieve the desired outcome.

Option 1 – Create a property group and use the SovLabs Property Toolkit to assign the desired properties.

As we did in Part 1, you will need to create property groups with all the properties and values included in Table 1.

Next, we need to create a property definition. Just like the property definition in Part 1 the format should be SVL_{your_unique_name_here}.  When you create your drop-down options — in this scenario we will use WordPress —  the value should be the name of the created property group that represents WordPress.  In my case is would be SVL_App_Wordpress.

Option 2 – Use the SovLabs Template Engine to dynamically determine some of the required values.

This example differs from what we did in Part 1. Here, we are going to require a Dynamic Property Group per application option.  Within each property group, some values will be static and some will be dynamic. This method is a hybrid approach in which we will drive as much as we can dynamically and the rest will be static.

The idea is to use the SovLabs Template Engine to perform the logic we need and not overcomplicate the solution. While I can think of many ways to create a single Dynamic Property Group, in the end, it would create more overhead and require more maintenance to the solution.

In Option 1 there is a limitation.  What if the resources assigned to an application differ for development, production, and test?  Option 1 is unable to support that use case. However, as you are about to find out, it can easily be supported with Dynamic Property Groups.  Let’s get started.

The below example is for Microsoft SQL Server

Table 2 

Now we need to create our Dynamic Property groups for our applications based on the values in Table 2.  

Once that task is complete, we need to create our property definitions, which will be used later as our application dropdown in the request interface.

With our application input complete we have just one input left to build.  The final input is the compliance input. The compliance input is going to be very similar to the environment input.

Let examine these inputs in the table below.

Much like our other two inputs, we now need to create our property group and property definition for the compliance input.  By now you should have a good idea how this process is done. If you need a reference, please refer to the environment input creation in Part 1 of this series.

In Part 1, we rubbed our magic lamp. Now the room is starting to fill with mystical fog, so much so that it’s starting to get a little cloudy in here.  As we head into Part 3, we will take these pieces and put them together and our magical genie will start to take form and appear out of the fog.

{% endraw %}