vRA – Get Reservation Policy ID from vRO

Introduction

I’ve been dealing with Reservations & Reservation Policies on vRA and found out that instead of using a SQL query, it was able to use vRO to pull Reservation Policy ID information out. In this blog post, I will go through both ways and explain the difference.

If you aren’t familiar with Reservation Policy ID, read the excellent blog by Kushmaro.

SQL Query

The following is the SQL query you could use in order to pull Reservation Policy ID out:

SELECT [id],[name] FROM [vCAC].[dbo].[HostReservationPolicy]

Login to SQL Management Studio and run the query above. If you don’t have access, ask database administrator to run it and get the output for you.

The attached screenshot below is a sample output:

5

It was quite easy, wasn’t it? Let’s take a look at vRO query.

vRO Query

It’s fairly simple to use vRO to query Reservation Policy ID. First of all, create a workflow and attach two attributes as the following:

6

For Reservation values, expand Reservations folder and add Reservations you would like to:

1

For vCACHost, select the vRA server.

Now, click on the Schema tab and drag and drop a scriptable task between start and end:

7

Edit the scriptable task and finish the Visual Binding like the below:

8

Navigate to Scripting tab and paste the script:

for each (var r in Reservation) {
  var reservationPolicyId = r.getEntity().getLink(vCACHost, "HostReservationPolicy");
  for each (var p in reservationPolicyId) {
    System.log("***********************************************");
    System.log("Reservation Policy Name is: ");
    System.log(p.getProperty('name'));
    System.log("Reservation Policy ID is: ");
    System.log(p.getProperty('id'));
    System.log("***********************************************");
  }
}

Run the workflow and a sample output is shown below:

4

Comparing both outputs from SQL and vRO, it seems different. There are 5 Reservation Policies from SQL whereas 3 from vRO. Why is this?

Difference

Let us first take a look at how many Reservation & Reservation Policies are there in the vRA environment I am connected to:

10

9

Even though there are 5 Reservation Policies, it does not mean that Reservations use all of them. In this case there are 3 Reservations and they are using only 2 Reservation Policies.

In summary, if you do a SQL query, it will show you Reservation Policy IDs across all Reservation Policies whereas vRO will only return you the ones being used by Reservations.

Hope this was useful and feel free to leave a comment for any clarifications.

vRO Deepdive Series Part 3 – Presentation Layer

Introduction

This is the third vRO deep dive series and in this blog post, it will be discussing presentation layer. Before starting, I recommend you to read previous 2 blogs:

Presentation Layer

What is presentation layer? Presentation layer is where you structure and apply logics to inputs. The modified structure and logics will be represented to users who run the workflow. Let’s recap last series’ example. The workflow had 2 inputs defined:

  • VM
  • Cluster

Executing the workflow shows you 2 inputs:

1

So where do I re-configure presentation layer? Edit the workflow above, “Sample Workflow” and on the 5th tab, you will see Presentation:

2

In this Presentation tab, there are five options available listed below:

  • Expand All
  • Collapse All
  • Create New Step
  • Create Display Group
  • Delete

Using the workflow above, I will first be going through creating & configuring step.

Step

In the presentation layer, step could be created to allow end-users to give inputs in multiple steps. Think it as a survey, rather than asking all questions in 1 page, survey normally separates out questions in multiple pages. Step is literally the same thing.

Let’s create a step. Edit the workflow, select Presentation and click “Create new step”:

3

And re-name it to “Step 1” by double clicking it:

5

Save the change made and close the window. Run the workflow and you will see a new step created:

6

Click Next and you will be at “Step 1”:

7

“Step 1” has nothing shown as there are no inputs mapped to it. Let’s allocate an input to it, go back to Presentation tab and drag VM into “Step 1”:

8

9

Execute the workflow and in Step 1, it will for VM:

11

Rather than Common parameters above, it would be better to call it Step 1 and then Step 2. Go back to the Presentation tab and create one more step:

12

Running the workflow, it will show you 2 separate steps:

13

14

This is the way of creating multiple steps and assigning values. I will now start discussing display group.

Display Group

Display group is where you could define multiple steps within a step. It sounds a bit confusing but it’s actually quite simple, go back to the workflow, select Step 1 and click Create display group:

13

14

Drag VM into Group 1:

15

Run the workflow and you will see within the Step 1, there is another step called Group 1:

16

This time, let’s put 2 inputs VM and Cluster into this group. Drag both inputs to Group 1 and delete Step 2:

17

Executing the workflow, it will show you Group 1 now asks for 2 inputs:

18

This time, let’s create 2 groups within a step. Select Step 1, create display group and drag Cluster into the second group:

19

Run the workflow and you will now see two groups in a single step:

20

21

One thing to note is that the display group could only be created within a step, i.e. display group in a display group isn’t possible.

Moving on to properties.

Properties

Properties is where you could apply logics to inputs. For instance, you could make an input as a mandatory field that the user must put it in order to submit the request. Let’s try this out, go back to Presentation tab, select VM input and on the bottom, click Add Property:

22

You will see the full list of properties you can apply to this input. Select Mandatory input and click OK:

24

Save the workflow and run it. Unlike before, you won’t be able to proceed without defining a cluster value, Submit button will be greyed out:

25

26

Instead of using a scriptable task within a workflow to ensure the input is given by user or trying to match it against a regular expression…etc, this is the simpler way.

Next exercise will go through how to predefine list of values, i.e. user will only be able to select a value from the predefined elements. Go back to Presentation, click on the cluster input, click Add property and select Predefined list of elements:

27

Click on the pencil button:

28

Wait a minute, there is no parameter available. Why? It’s obvious that we haven’t created any attributes with pre-defined values. Take a close look at the heading of the window “Linked parameter of type Array/VC:VirtualMachine”. This is because the input is defined as VC:VirtualMachine object and since we are trying to predefine values, the final object should be Array/VC:VirtualMachine.

29

Let’s create an attribute. Go to General tab and Add an attribute called VMList with Array of VC:VirtualMachine:

30

Once created, click on Not set to insert values. In my case, I pre-defined 4 values:

  • test1
  • test2
  • test3
  • test4

31

32

Go back to Presentation tab and click property of VM. You will now see VMList:

33

Accept it and run the workflow. Select VM and now it will have predefined list:

34

There are a lot of properties you could play around with, spend some time adding different properties to input values.

Wrap-Up

Hope this blog post was helpful and the next series will cover “Log Handling, Throwing Exceptions and Fail-back”. Stay tuned 😀

vRO F5 Plugin – Pools Not In Common Partition Not Shown

Introduction

I’ve been working with vRO F5 plugin recently and found an interesting behaviour that I would like to share. In this blog post, it will be discussing:

  1. Environment
  2. Task
  3. Interesting Behaviour
  4. Wrap-Up

Environment

The following is the list of products with versions I used:

  1. vRealize Orchestrator version 5.5
  2. F5 version 11.5.2
  3. F5 vRO plugin version 2.0.1

Task

The task I tried to achieve with the F5 vRO plugin is to:

  1. Attach LTM server from vRO
  2. Create a pool under a partition called “Production”
  3. Add a member under the pool created
  4. Delete the pool

And the list of built in workflows attached below:

1

First of all, I tried to attach LTM server by running “Attach LTM” workflow:

1

F5 plugin version 1.x.x uses SOAP API and from 2.0.0, they introduced a new support for REST API. As I wanted to stick to SOAP API, I’ve set false to REST API flag and clicked Submit.

As per the task above, second step was to create a pool under Production partition. Running the “Create Pool” workflow, inputs required were:

  1. LTM Instance
  2. Name for pool
  3. Method

As shown below, there was no input to specify which partition I wanted to create a pool in:

2

Wanted to check which partition the pool goes into. Executed the workflow with the attached LTM server giving a name “StevenTest”.

Looking at the Logs tab:

3

And the F5 Pools List page:

4

As expected, it was created under Common partition. How could I add a pool under Production partition? One thing came up in my mind was, what would happen if I give the full path i.e. /Production/StevenTest as the name. This time, for the name, I used /Production/StevenTest1:

5

Wallah, it worked! The pool was created under Production partition:

6

On the pool I created, I executed “Add Pool Member” workflow to add a member to it. One of the inputs was LTM Pool. Clicked on it and found out that I couldn’t see /Production/StevenTest1 pool:

Screenshot 2015-04-20 17.46.35

7

So by the look of it, only pools in Common partition could be found. Why is this the case?

Interesting Behaviour

I was looking at all API calls, blog posts from F5, literally everything I could but there was no luck to fix this issue. Then I realised that would this still be the case if I use REST API instead of SOAP API? I gave it a go, detached the LTM server and attached it again enabling REST API:

8

9

Once done, I navigated to Inventory Tab and expanded F5 Networks and guess what, the pool created under Production partition was there:

10

Ran “Add Pool Member” workflow again using port 443:

13

14

And checking the member created from Members tab on F5 interface, it was successfully made under Production path.

15

The final step was to delete pool. Ran “Delete a pool” workflow selecting /Production/StevenTest1 pool:

4

Looking at the pools list from F5 interface, it was gone:

18

Wrap-Up

The behaviour I found, wondering if this is a bug. Will be sending an email to F5 vRO plugin to confirm if it is the case. Otherwise, will try to get a solution or workaround. Will update this post once I get an answer from them.

Hope this was helpful and feel free to leave a message for any clarifications 😀