A request for Powershell Toolkit....

[JGPSHNTAP]

I've made this in the past, but i'm hoping we can make some headway on this Feature Request.

I've been an active user since PSTK 1.0, and i'm confused as the direction that was taken with cDOT.  I'm not a developer, but I'm hoping someone can shed some light on this.

For example, if we want to query a vserver for volumes that aren't part of drprotection I do something like this

C:\powershell> get-ncvol -Vserver vserver1 | select name,@{n='protection';e={$_.VolumeVserverDrProtectionAttributes.vserverdrprotection}} | ?
{$_.protection -ne "protected"}

That's all well in good, but I should ne able to pass this to an update command, not update-ncvol where we have to build queries to fix this.

Am I totally missing something here?

[asulliva]

Hello @JGPSHNTAP,

I'm not quite sure I understand your request.  I think what you're asking for is to have "Update-NcXXXXX" cmdlets for each of the properties associated with a volume (among other objects)?

If that's true, then I do sympathize with your sentiment as it would make the most sense from a usability perspective.  However, the ONTAP modules are created to mimic ZAPI functionality.  In this instance, these volume attributes are all updated by the "volume-modify-iter" ZAPI (which maps to the "Update-NcVol" cmdlet).

I can not (and will not try to) rationalize or justify the engineering decision behind this since I wasn't a part of it, but I do also empathize with the engineering team.  Having each of these be a separate cmdlet (really, multiple cmdlets, since there would be both a Get and Set/Update cmdlet, and in some cases a Remove too) would create a tremendous number of additional cmdlets, easily several hundred, which need to be individually maintained and updated.

Again, while I'm not defending the current status, it is quite easy to select the volumes using a query:

Get-NcVol -Query @{ VolumeVserverDrProtectionAttributes = @{ VserverDrProtection = "!protected" } }

And, updating them is similarly easy:

# update all volumes from anything other than "protected" to "protected"
Update-NcVol -Query @{ Vserver = $svmName; VolumeVserverDrProtectionAttributes = @{ VserverDrProtection = "!protected" } } -Attributes @{ VolumeVserverDrProtectionAttributes = @{ VserverDrProtection = "protected" } }

# update only specific volumes
Update-NcVol -Query @{ Name = "protectMe_*"; Vserver = $svmName; VolumeVserverDrProtectionAttributes = @{ VserverDrProtection = "!protected" } } -Attributes @{ VolumeVserverDrProtectionAttributes = @{ VserverDrProtection = "protected" } }

For those which you find yourself using frequently, you could create your own cmdlets.  I have examples of how to do that for QoS here.

Hope that helps.

Andrew

[JGPSHNTAP]

^^

I'm not doubting what you say.    But i've been around PS toolkit since 1.0, and some of my older scripts for 7-mode were so much easier.  That's purely my opinion.

I'm not a developer, so I'm not sure why they have all the extended attributes, but in my opinion, I should be able to do this. (just an example)

get-ncvol | ? {$_.vserverdrproperties -ne "protected"} | update-ncvol  "protected"

The whole building a command hash table to update seems quirky to me.  Again, that's just my opinion.

Back in the day when Cliff knight was writing it, we would have correspondence with him, but he told me a while ago he moved on to other roles.    

Believe me I appreciate all the hard work that went into PS toolkit, but I feel like there has to be improvement.

I can write the exact same code you have below, but the point is, for most guys, they want to be able to do traditional PS.  That reminds me of Quest AD cmdlets before MS released their own.  They just feel quirky to me.

I will gladly have a call with you if you would like.   

[asulliva]

I forgot to mention in my previous reply that this is something I'm happy to bring up with the product management team to discuss the level of effort and whether it's feasible to add.  I can't make any guarantees, but I do believe it could be a valuable addition and increase the usability of the ONTAP module.

Andrew