#Use powershell or Python cli passtrough

1 messages · Page 1 of 1 (latest)

spark grove
#

So im trying to figure out if i should continue with our powershelll script for monitoring our systems or instead try python CLI passtrough and do something with that. Anyone have any advice whats better.
Also is NetApp cutting support for powershell ? Since rest api it seems that alot of cmdlets is not working correctly any longer.

slow basin
#

My group (Lab on Demand) uses Powershell and Python extensively. We have noticed that the 9.13 NetApp.ONTAP powershell module has changed behavior and requires refactoring of some (many?) cmdlet inputs and defining some parameters that were not previously required. That’s to say, they don’t not work, but have had breaking changes that require refactoring.

pine shale
#

If you’re more comfortable with powershell you can do the REST calls yourself as well as CLI passthrough with Invoke-RestMethod.

slow basin
#

That's true too! There are a few APIs new to 9.11 that I don't think even have cmdlets yet...

spark grove
#

While i look into using Python i realised we need to continue use our old scripts so im going to rewrite them. But i im been having a hard time grasping how REST API works with powershell since i do not seem to be able to get as much information as before with ZAPI API cmdlets or info at all.

Could not really find any good info on this from NetApp. But i found this forum thread where there was some response at least.

https://community.netapp.com/t5/Microsoft-Virtualization-Discussions/Feedback-from-REST-testing-with-PSTK/td-p/447627

quoted from thread:
"I understand that you are looking for "vserver type" property in Get-NcVserver cmdlet. But unfortunately, we don't have any control over this because SVM REST API is designed to manage data svm only hence vserver type is not supported in rest call. For the same reason in other cmdlets also you may notice some properties are missing because of the REST API limitation."

So the REST API does not go as deep as ZAPI did. And never will ?
So its a worse API in some regard since it cant fetch all data from the clusters.

This gave me a big headache i tought it was a bug with my powershell version. Will have to rewrite alot more i guess or maybe retreive data from unified manager or maybe trough the CLI passtrough. i dont know right now whats best.

Anyway, any mor knowledge how to use/setup the CLI passthrough with Invoke-RestMethod ?

slow basin
#

It does, but you may have to explicitly request the fields you want in the API. ONTAP clusters are massive with regard to metadata. There are thousands of parameters associated with any one object (such as a vserver or volume). It's unlikely that the base API will provide everything.

For example, I was trying to get all volumes on a vserver and it was causing an 'out of memory' (OOM) situation on my little dev VM. The same could look like a timeout as well... I redesigned the query to only provide the name and volume size.

spark grove
#

Then i must be piping the data wrong. Most fields i encounter is empty or filled with some generic message "DataONTAP.C.Types...."
Or do i specifically go trough the REST API with powershell for the fields to be populated.
The cmdlets is not working correct. Even some of the most basic fields like "Used" using get-ncvol does not give me that field populated i guess i would have to code it to calculate the difference from "TotalSize" and "Available". Annoying but ok.

But here is another thing i found using for example Get-Ncaggr and piping that to show me all info about my aggregates gave me about 135 rows of information.

I ran the same command with -ZapiCall and it gave me about 234.

Some of those is root aggregate fields but could not account for all i think.

You know if there is some documentation about how to use the new APi with powershell ? Its rather sparse with technical info from NetApp about this transition

spark grove
#

Found labondemand there seems to be some tutorial there on Rest API

slow basin
#

I think I misunderstood the context. If you say that you’re using the RestAPI, I understand that as you are building the API path and using Invoke-RestMethod. If you’re using the NetApp.ONTAP module, that’s different. The part of my response concerning the OOM stuff was Python…

spark grove
#

Yes, no, i meant the restapi trough the NetApp.ONTAP module. But i maybe can achieve what i want with Invoke-RestMethod

slow basin
#

There’s also a behavior that I’ve not looked into that I experienced when working with the VMware.PowerCLI module. I suspect this behavior/approach is good for our complex objects. Here’s what I saw:
Connect to vCenterA
Get a vApp object into a variable
Disconnect vCenterA
Connect to vCenterB
Attempt to reference nested attributes of vAppA to built vAppB
All attributes are incorrectly $null

What I learned is if I did not reference these attributes before disconnecting, the appropriate APIs were not pro-actively executed. It’s probably “lazy execution” or something.

Due to the inordinate amount of meta data that an object in ONTAP is likely to have, I bet it’s implemented similarly. I’ve been OOTO/AFK since Thursday and until Tuesday, so I can’t test this myself. But you have the LOD lab at your disposal. Just don’t save unique data in there as the labs are backed by flexclones and once gone, it’s gone.