NetApp has just released the first version of their PowerShell Toolkit last week. Overall, I am really impressed with their implementation. They did a bunch of things right.
It’s a PowerShell 2.0 Module
Lots of great help files for every Cmdlet
Full coverage of the ONTAP API
Used “Approved” verbs
About a year ago, NetApp released a .NET version of their API. Using their DLL, I was able to write a bunch of PowerShell 2.0 Advanced Functions to automate the 20 or so tasks that my team did with our NetApps on a weekly basis. Using the .NET API, I created a module with 20 or so Advanced Functions. So far, every one of them has been implemented in the new cmdlets. There are also a great deal of cmdlets that are extremely useful that I never got around to writing.
The ONTAPI .NET API exposed functionality with an object of type Netapp.Manage.NaElement, which is basically an XML Element. Essentially, everything in the Netapp API takes in XML and returns XML. PowerShell does a great job with XML and it was relatively easy to cast from XML to PSObjects as needed. However, the new PowerShell toolkit has a bunch of wrapper classes which seem to be a bunch of de-serialized NaElement Objects. This makes working with the objects much easier.
NetApp has really done a terrific job with their adoption of PowerShell. Again, I am particularly impressed with how well they adhered to the “ground rules” for working with PowerShell. In my opinion, these cmdlets are a great example for other third party companies that are looking to adopt PowerShell.
Now, this is of course version 1. There is always room for improvement. One of the first things I noticed is that there could have been some work done on the default formatting for some of the most basic objects that we use all the time, particularly luns and volumes, NetApp.Ontapi.Filer.Lun.LunInfo NetApp.Ontapi.Filer.Volume.VolumeInfo respectively. Frankly, I like the default view to be a table with 4 or 5 critical columns. If something has to default to format-table, its too much information to process for me, but that’s my humble opinion.
Here’s an example
I think I would prefer to have a table view that just shows the name, sizeTotal, SizeUsed, and perhaps 1 or 2 other attributes. This seems more useful out of the box to me
NetApp filers are SAN’s. They are all about storage. They are built on a hierarchical model. Frankly, I think a PowerShell Provider could be a great fit for managing a NetApp filer. However, as Jeffrey Snover often says, to ship is to choose, and I wholeheartedly belive that the cmdlets are more useful than just a provider. But, if you have a provider and cmdlets, they are definitely better together. I love using a Provider for discovery purposes. But I think in general, cmdlets are more useful for actually executing tasks. I would love to see a complimentary PS Provider in version 2 of the Toolkit.
All that being said, I tip my hat to Netapp. Great job on version 1!