So here I go again… I hit another roadblock and I would like your opinion. As I go through the Netapp OnTap SDK I’m finding a lot of duplication. At first I went the VMware path and was building one Cmdlet for every possible task. This methodology is heavily dependent upon the pipeline for usability sake. For example take the following…

So that’s all great right? Here’s my issue NetApp has several API’s for both Volumes and Aggregates that are identical. Well almost, they perform the same functions, but take different parameters. So would you rather have 25 cmdlets that perform very specific tasks? Or 10 slightly more complicated cmdlets? I’ll elaborate a little further…
etApp has two base storage allocation methods and aggregate, and a volume. For those of you who don’t know a Volume is what you would concider a traditional raid. An Aggregate is a logical unit that contains Flexible Volumes. They perform the same exact function, but maintain different usecases. Therefor the OnTap API treat’s them seperatley even when they are performing the same function. i.e.
Raid Validation:
The process of validating the integrity of a given unit.
1 2 3 4 5 6 7 8 9 10 11 12 13 14 15 16 17 18 19 20 21 22 23 24 25 26 27 28 29 30 31 32 33 34 35 36 37 38 39 40 41 42 43 44 45 46 47 48 49 50 51
|
Cmdlet Start-NaVolVerify { param( [Parameter(Position=0,Mandatory=$TRUE,ValueFromPipelineByPropertyName=$TRUE,HelpMessage="Name of the mirrored traditional volume to verify. ")] [STRING] $volume, [Parameter(Position=1,HelpMessage="If provided, this specifies the plex to fix.")] [INT] $FixPlex, [Parameter(HelpMessage="[PSObject]NAserver (New-NAServer)")] [Netapp.SDK.NaServer] $server ) $request = New-Object NetApp.SDK.NaRequest -ArgumentList @("volume-verify-start") if ($volume) { $request.AddParam("volume",$volume) } if ($FixPlex) { $request.AddParam("fix-plex",$FixPlex) } $result = Get-NaResult -request $request -server $server return $result.status } Cmdlet Start-NaAggrVerify { param( [Parameter(Position=0,ValueFromPipelineByPropertyName=$TRUE,HelpMessage="Name of the mirrored aggregate to verify")] [STRING] $Aggregate, [Parameter(Position=1,HelpMessage="If provided, this specifies the plex to fix in case the two plexes do not match. The default is to log any discrepancies instead of fixing them")] [INT] $FixPlex, [Parameter(HelpMessage="[PSObject]NAserver (New-NAServer)")] [Netapp.SDK.NaServer] $server ) $request = New-Object NetApp.SDK.NaRequest -ArgumentList @("aggr-verify-start") if ($Aggregate) { $request.AddParam("aggregate",$Aggregate) } if ($FixPlex) { $request.AddParam("fix-plex",$FixPlex) } $result = Get-NaResult -request $request -server $server return $result.status } |
As you can see they are identical in use, and indeed perform the same task. The rational for keeping them separate is simple. Per the OnTap API within the Start-NaAggrVerify Cmdlet the target is specified via an “aggregate” parameter. Likewise the Start-NaVolVerify has an identical parameter but named “Volume”. As you can see the simple approach is to keep them separate, but when you consider that there are at least four Cmdlets dealing with verification, and at least five API’s like it. The Cmdlet count quickly get’s bloated and confusing (or at least I think it does). The alternative is to add a param and require more from the admin at runtime. Ala
1 2 3 4 5 6 7 8 9 10 11 12 13 14 15 16 17 18 19 20 21 22 23 24 25 26 27 28 29 30 31 32 33
|
Cmdlet Start-NaVerify { param( [Parameter(Position=0,ParameterSetName="vol",ValueFromPipelineByPropertyName=$TRUE,HelpMessage="Name of the mirrored traditional volume to verify.")] [STRING] $volume, [Parameter(Position=0,ParameterSetName="aggr",ValueFromPipelineByPropertyName=$TRUE,HelpMessage="Name of the mirrored aggregate to verify.")] [STRING] $Aggregate, [Parameter(Position=1,HelpMessage="If provided, this specifies the plex to fix.")] [INT] $FixPlex, [Parameter(HelpMessage="[PSObject]NAserver (New-NAServer)")] [Netapp.SDK.NaServer] $server ) process { if ($volume) { $request = New-Object NetApp.SDK.NaRequest -ArgumentList @("volume-verify-start") $request.AddParam("volume",$volume) } elseif ($Aggregate) { $request = New-Object NetApp.SDK.NaRequest -ArgumentList @("aggr-verify-start") $request.AddParam("aggregate",$Aggregate) } if ($FixPlex) { $request.AddParam("fix-plex",$FixPlex) } $result = Get-NaResult -request $request -server $server return $result.status } } |
On the one hand I personaly do not like this approach because it leads to an obscure and misleading syntax, but it is the only way I know to prevent “cmdlet sprawl”. So what do you think is it okay to require one or three extra parameters per, or would you rather see separate perpouse built cmdlets? Keep in mind I’ve only converted Volumes, Aggregates, licenses, Disks, and Snapshots. That is a total of five out of 40+ regions and I’ve already amassed some 46 cmdlets!
Is there such thing as too many cmdlets?
~Glenn
And yes I know that all my code will break with ctp3… I would rather update it for the new syntax in dec. Then wait and be stuck in v1 fuctions, or code cmdlets! 😉