This content was originally posted on Eastside Geek.
ViPR SRM is a powerful tool for manipulating large sets of data. In previous posts we've explored how to do things like modify the built-in Collectors - a fairly advanced topic. For this one, let's dial it back and review one of the basic arrows you'll need in your quiver to customize SRM effectively.
Setting up the Sandbox
First go to Edit Mode - if you don't see this link, ask your SRM administrator nicely to add this account permission. If that doesn't work, move on to blackmail through clever Photoshopping.
From there, make sure you've highlighted 'My Reports' and create a new node. Scroll down to see your new node in the hierarchy, then go ahead and give it a name.
Next, we're going to set the filter. In this example, I'm going to show port data from some SAN switches. This should work the same whether you use Cisco or Brocade. If you don't have SAN switches discovered, try swapping out FabricSwitch/Port for another devtype/parttype pair, like Array/LUN or VirtualMachine/Disk.
Building a Filter
The magic words for the ViPR SRM data model are
devtype - A type of device, such as Array, Host, or FabricSwitch
device - An instance of a devtype, such as VMAX 1234 or host sqlserver01.domain.net
parttype - A type of subcomponent associated with a device, such as a port, disk, or CPU
part - An instance of a parttype, such as Port 1/1, Disk 04EC, or CPU 0
name - A time-series metric that is associated with a device or part, such as CPU Utilization or Frames in per second
Most everything in the SRM database can be tracked down some combination of these five magic words. A wizard in training would do well to remember them.
In this case, we want to build a report which shows information about all ports on all switches, so we'll build a filter to capture just that data.
We'll choose to look for devtype=='FabricSwitch', then add parttype=='Port'. The end result should look something like this.
If to some of you eagle eyed observers this looks like the WHERE clause in a SQL statement, you'd be correct. The funny little box that starts with 'Everything' is a GUI for building just that.
Basic Report Setup
Since we don't want this to be a simple list, over in the Report Configuration tab we're going to select Standard Table for the report type.
Then we'll mosey over to Report Details where we'll add two new Property columns. One will be called 'Switch' and reference property 'device'. The other will be called 'Port' and reference property 'part'.
Now let's hit Save and go back to Browse mode to see what we've done.
Wait, something's not right here. Why do we have all those instances of Port 0 on losbe175? Why are there over 10 thousand elements in my table? Clearly we've missed something.
The thing we missed was adding an expansion. An expansion tells SRM how to dice up the results of the report query (which you'll recall we narrowed with Filter devtype=='FabricSwitch' && parttype=='Port' above).
What does that mean? One easy way to think about it: An expansion defines the scope of what you want to be on each individual line of your table.
Still not clicking? That's fine, we're going to try it a couple of different ways and look at the results.
If you want an expansion to apply to this table, it needs to be on a child of the node where your table lives. That means we'll need to add a child node.
Once the node has been added, let's try to make an expansion on 'device', which should cause our table to show one switch per line.
Save the report and head back to Browse mode to see what this has done.
Since there are many 'part' properties associated with this device (ie, each switch has lots of ports) the column for property 'part' will list all associated ports in a comma separated list.
Let's flip that on its head now. Go back to Edit mode, remove the expansion on 'device' and add an expansion on 'part'
Now let's see what the report looks like in Browse.
Now we've got one port per line, and we see the same phenomenon in reverse: where multiple switches have the same port name ('14' or 'fc1/10'), the 'device' column shows a comma-separated list of those switches.
Wouldn't it be nice if each line of the table actually represented a unique physical port in the environment? To get that, we'll need to tell SRM to make each line a unique combination of switch and port.
To do that, we'll specify a grouped expansion on the child node, like so:
Once that's done, the report should look something like this:
Now let's add some columns that will provide some insight into what's going on. To do that, go back to the Report Details of the table and add a pair of Attribute columns. Make one the 'node name' and the other the 'global filter'.
Now the report will look something like this:
As you can see, the Attribute 'node name' shows the names of the expansion element(s) particular to the row. The 'global filter' shows the filter which applies to that row - as you can see, it's a combination of the Filter we set originally and a unique filter for each device/part pair. If you were to switch this attribute to 'node filter', you'd see just the second chunk.
To Be Continued...
This report will be the basis of some future posts. In the meantime, spend some time playing with different combinations of expansions in your My Reports sandbox.