November 2008 - The Practical Administrator

Using –SupportsShouldProcess in Powershell V2 ScriptCmdlets

2015-12-212008-11-25 by Glenn

Okay so I’m a bit of an early adopter. My main admin rig at work has been running V2 for the past year. In the last six months I’ve fallen in love with scriptcmdlets. One thing that constantly reminded me that this was still a CTP, and not a shipped product was –SupportsShouldProcess. The included about docs are misleading at best. The hidden user guide in %windir%System32WindowsPowerShellv1.0en-US had nothing, and perhaps the biggest shock of all. There was nothing on the web. The only thing I could find was this PDF from a Server 2k8 launch event. I started to think I was the only one who wanted this functionality. Well all I needed was handed to me on a golden platter this morning when Mr. Snover posted this. At last, a working example!

To keep this as easy as possible take the following V1 function:

Now let make it a V2 scriptCmdlet:

Finally let’s give this little guy some kick!

Why should you care? Well simple I added three lines of code and one parameter. Look at all the functionality the PowerShell Team provided me with that small amount of code!

There you have it script cmdlets ShouldProcess support. Hope that helps anyone who’s been trying to figure that out.

~Glenn

Can you have too many Cmdlets?

2015-12-212008-11-18 by Glenn

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.

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
}

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

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
    }
}

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! 😉

You Might have a memory leak if…

2015-12-212008-11-10 by Glenn

Your PowerShell session consumes 4GB of ram in less than 3 seconds…

while I didn’t think vista was suppose to allow such things. My code caused the crash not PowerShell itself!

~Glenn

Update: okay so a decimal point blew it up! The Netapp API returns the dtg in the form of a int64. Without adding an explicit cast powershell treated it as an int. What does that mean? Well it’s the difference between the following:

My code…
[datetime]::FromFileTime(116444916000000000 + ($_.”last-scrub-timestamp”) * 10000000)

At run time this became:
[datetime]::FromFileTime(116444916000000000 + 1.226210494E+16)

and it blows up VERY quickly, vs:

New code:
[datetime]::FromFileTime(116444916000000000 + int64 * 10000000)

at run time:
[datetime]::FromFileTime(116444916000000000 + 12262104940000000)

Sunday, November 09, 2008 6:01:34 AM

Playing with DateTime in PowerShell

2015-12-212008-11-03 by Glenn

I recently had to convert the DTG( Date Time Group ) from NetApp to Windows. My tool of choice PowerShell! First things first what is the base of get-date. Turns out that was the easy part.

A quick round of developer speak over at MSDN revealed that the base of datetime was 1 tick. A tick is defined as 100 nanoseconds… put that aside for a second. NetApp records time by the number of seconds that have elapsed since 1/1/1970 12:00 AM. So how do I convert NetApp seconds to ticks… The mathematicians in the room (calling you out Andrew) will certainly know a more elegant methodology, but this poor admin settled on the following.

First, convert 1/1/1970 12:00 AM to ticks!

Okay, so where do we go from here? Remember that number from before 100 nanoseconds… This is where it got fun. Since the NetApp reports in seconds since 1970, and DateTime works in ticks. What we really need is to convert seconds to ticks. Well a quick live search (okay so I used goggle but live is getting better!) revealed that there are approximately 10000000 ticks in a second. Knowing that, the formula should be something like (Ticks to 1970) + ((seconds since 1970) * (number of Ticks in a second)).

Does it work?

I Love this shell! Now my example is not a very general purpose one, but the core logic doesn’t change.

Recap:

[System.Datetime] – core time measurement is a tick.

Tick – a tick is 100 nanoseconds.

Seconds – There are 10000000 ticks in a second.

~Glenn

Oh yeah and PowerShell ROCKS!

PVUG Meeting #7 Announced!

2015-12-212008-11-01 by Glenn

PowerShell virtual user group meeting #7 will be on Thursday November 13th 2008! It’s been a while since Marco has put one of these together. Understandable given all the work he does. If you’ve never attended one before I highly recommend it. Looks to be another all start lineup with Nathan Winters (MVP), Joel ‘Jakul’ Bennett, and a product demo by Ideara (cross your fingers for Tobias!). Remember these events are participation driven so, Go HERE NOW!

See you there,
~Glenn

UPDATE: I’ll be in Chantilly on the 13th 🙁 with a little luck I’ll get an (early am|late pm) flight back to Augusta, and be able to attend!