nav[aria-label="Primary Navigation"] { padding: 0; & ul { list-style: none; width: 100%; display: flex; flex-direction: row; justify-content: start; align-items: start; gap: 30px; padding: 0; & li { margin: 0; } & ul li { list-style: none; } } }

Component react.community-search had an error.

ref must be one of: categoryID, siteSectionID, category, category/categoryID, category/name, category/description, category/url, category/allowedDiscussionTypes, locale, siteSection, siteSection/basePath, siteSection/contentLocale, siteSection/sectionGroup, siteSection/sectionID, siteSection/name, siteSection/description, siteSection/apps, siteSection/attributes, layoutViewType, discussionID, commentID, page, latest, sort, sortType, lookupSort, discussion, discussion/name, tags, breadcrumbs, discussionApiParams, serverDraftID, serverDraft.

Feedback from REST testing with PSTK

StevePutre

Recently, I have performed testing to get our current set of Powershell scripts working with REST API. I would like to share some of my results, in the spirit of trying to improve the product and ease our transition from ONTAPI to REST API

I tested a number of existing Powershell scripts which my team has developed over the years. I tested with PSTK v9.13.1.2306 and OnTAP v9.10.1p12

On the positive side, the very basic functionality is there. You can "drop in" the new PSTK package into Windows, use the same cmdlets with REST and ONTAPI, and they work at a basic level. PSTK hides the complexity of the underlying calls and provides a consistent set of cmdlets.

On the not-so-great side, many common cmdlets (get-ncvol, get-ncvserver, et-ncsnapshot to name a few) do not return all of the properties with REST which they do with ONTAPI. Since my scripts require these properties to be returned, I am unable to use the REST API and have to specify -ONTAPI for many of my calls.

There are other issues with REST, among them:

REST calls in some cases are much slower than the same call with ONTAPI,
The help pages for the cmdlets in many cases have not been fully updated to match the cmdlet (example the -ONTAPI option is not even mentioned),
Some cmdlets behave differently with REST than with ONTAPI. I have seen the REST flavor return a Warning message that the ONTAPI flavor does not. While this is not a functional issue, it requires me to change my code to suppress or handle the warning message.

I would be happy to share specific cmdlets which I have tested and which are inconsistent between REST and ONTAPI

I call on the PSTK maintainers to continue to improve and evolve the toolkit to provide consistent functionality, behavior, and performance between REST and ONTAPI flavors of their cmdlets.

I would encourage other users to post their replies here, regarding their experience in migrating to REST with PSTK.

Find more posts tagged with

Hyper-V

Comments

AmmarMhowwala

Thankyou for the feedback
Regarding difference in behaviour in cmdlets from ZAPI to REST, there are two main reason for this either REST API may not support few feature or functionalities with respect to zapi or may have introduced alternate way to support the same feature.
for the same reason Get-NcVol does not return all of the records that zapi does because rest api does not return "Node root volume" and "system vserver volume" type volume while zapi return all these type of volumes that is why you are getting different result with zapi and rest for this cmdlet.
It would be very helpful if you could share specific command where you have encounter performance issues by enabling logs using "Set-NaToolkitConfiguration on" also please share the command where you find gap in the help document we will update the document. we did not add -ONTAPI parameter in help document because it is generic parameter and zapi will going to be deprecated in near future
Please feel free to reach out for any queries.
thanks

StevePutre

Hi Ammar:

Thanks for your reply.

Here is an example of a performance difference using 'get-ncvserver'. Please refer to the attached output. I had to remove proprietary info from the output. The cluster in this example contains about 55 vservers. get-ncvserver using REST takes over a minute to complete, and get-ncvserver using ontapi takes less than five seconds:

PS E:\> Measure-Command {get-ncvserver -ontapi}

Minutes : 0
Seconds : 2

PS E:\> Measure-Command {get-ncvserver}

Minutes : 1
Seconds : 19

get-ncvserver.txt

StevePutre

Regarding my comment about REST calls not returning all information, here is a specific example using get-ncvserver. The REST form of the command does not return the property 'vservertype'. I rely on this property in many of my scripts:

PS E:\> get-ncvserver -ontapi myvserver | select vserver,vservertype,allowedprotocols,state,snapshotpolicy

Vserver : myvserver
VserverType : data
AllowedProtocols : {nfs, cifs, ndmp}
State : running
SnapshotPolicy : default

PS E:\> get-ncvserver myvserver | select vserver,vservertype,allowedprotocols,state,snapshotpolicy

Vserver : myvserver
VserverType :
AllowedProtocols : {cifs, nfs, ndmp}
State : running
SnapshotPolicy : default

This is only one example of a missing property. I have found numerous cases of this. Some of the cmdlets I have found which omit properties with REST are:

get-ncVserver

get-ncSnapMirror

get-ncVol

get-ncEmsEventNotification

get-ncNetRoute

If there is a workaround which would allow me to get those properties, I would be happy to implement it. But we cannot transition to REST unless we are reasonably confident that all expected output is being returned.

Thanks for your consideration of this issue.

AmmarMhowwala

Hi Steve, 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. In relation to performance, I have observed that when executing the same cmdlet (Get-NcVserver) within my environment, the REST API requires approximately 3 seconds to complete, whereas the ZAPI takes approximately 4 seconds. This observation has prompted me to explore the possibility of performance-related considerations within your environment. We will further investigate this matter.

goodmanr0732

I am also seeing commands taking significantly longer with the REST API calls vs ONTAPI.

PS C:\> Measure-Command -Expression {Get-NcVol}

Days : 0
Hours : 0
Minutes : 2
Seconds : 52
Milliseconds : 794
Ticks : 1727945486
TotalDays : 0.00199993690509259
TotalHours : 0.0479984857222222
TotalMinutes : 2.87990914333333
TotalSeconds : 172.7945486
TotalMilliseconds : 172794.5486

PS C:\Users\x060622> Measure-Command {Get-NcVol -ZapiCall}

Days : 0
Hours : 0
Minutes : 0
Seconds : 12
Milliseconds : 409
Ticks : 124091028
TotalDays : 0.000143623875
TotalHours : 0.003446973
TotalMinutes : 0.20681838
TotalSeconds : 12.4091028
TotalMilliseconds : 12409.1028

saharsh

From the 9.15.1 release, a new parameter will be introduced: hydrate, which will allow Yes, No, Partial.

Yes, this is the default behaviour as it stands now. After a successful API call, it would fetch the full result.

No: will it pass?return_records=true in the REST API, and then it will display any fields ONTAP configured (usually just keys, but sometimes a few more).

Partial: it will be responsible for fetching only the important properties of the commandlet.

After introducing the hydrate feature, the time related concerns will be fixed.