Hi all,   We have an interesting case here where some volumes' relationships are not listed in snapmirror list-destinations REST api.   However, these volumes' relationships are clearly visible and present in both ontap console and REST api CLI passthru as described below.   The problematic volume used in this case is SL10248 but there are more.  Our ontap is  NetApp Release 9.7P13: Thu Apr 15 02:06:46 UTC 2021   Check the SL10248 relationships using ontap CLI, observe two relationships present con-svm-201::> snapmirror list-destinations -source-volume SL10248 -instance Source Path: con-svm-201:SL10248 Destination Path: con-svm-201_SVMDR:SL10248 Relationship Type: XDP Relationship Group Type: vserver SnapMirror Policy Type: async-mirror Relationship Status: Idle Transfer Progress: - Progress Last Updated: - Source Volume Node: con-stor-02 Relationship ID: 32747509-db36-11eb-b628-00a098997ee7 Source Path: con-svm-201:SL10248 Destination Path: rt1aae:SL10248 Relationship Type: DP Relationship Group Type: none SnapMirror Policy Type: async-mirror Relationship Status: Idle Transfer Progress: - Progress Last Updated: - Source Volume Node: con-stor-02 Relationship ID: fa107abb-aab8-11e7-9c1c-00a098b72ab5 2 entries were displayed. con-svm-201::> Check the SL10248 relationships using REST API CLI passtgrough. Observe two relationships present, same as above: simacr@simacr-linux:~$ curl --insecure --user user:pass "https://con-svm-201/api/private/cli/snapmirror/list-destinations?source-volume=SL10248&fields=relationship_id" { "records": [ { "source_path": "con-svm-201:SL10248", "source_vserver": "con-svm-201", "source_volume": "SL10248", "destination_path": "con-svm-201_SVMDR:SL10248", "destination_vserver": "con-svm-201_SVMDR", "destination_volume": "SL10248", "relationship_id": "32747509-db36-11eb-b628-00a098997ee7" }, { "source_path": "con-svm-201:SL10248", "source_vserver": "con-svm-201", "source_volume": "SL10248", "destination_path": "rt1aae:SL10248", "destination_vserver": "rt1aae", "destination_volume": "SL10248", "relationship_id": "fa107abb-aab8-11e7-9c1c-00a098b72ab5" } ], "num_records": 2 }simacr@simacr-linux:~$ Check the snapmirror relationships using proper REST API call. List all relationships to avoid filtering ambiguities. Redirect to file due to size. Grep the output for SL10248 AND by UUID to confirm the missing relationships. Show the output sample to prove the output contains valid data, but incomplete regarding SL10248: simacr@simacr-linux:~$ curl --insecure --user user:pass "https://con-svm-201/api/snapmirror/relationships/?list_destinations_only=true&fields=source" >o % Total % Received % Xferd Average Speed Time Time Time Current Dload Upload Total Spent Left Speed 100 137k 0 137k 0 0 9628 0 --:--:-- 0:00:14 --:--:-- 9869 simacr@simacr-linux:~$ grep SL10248 o simacr@simacr-linux:~$grep 32747509-db36-11eb-b628-00a098997ee7 o simacr@simacr-linux:~$ grep fa107abb-aab8-11e7-9c1c-00a098b72ab5 o simacr@simacr-linux:~$ more o { "records": [ { "uuid": "000e6732-d8a1-11e9-8b45-00a098b98617", "source": { "path": "con-svm-201:SL10573", "svm": { "uuid": "73b41add-0450-11e7-a1f7-00a09876f5a4", "name": "con-svm-201", "_links": { "self": { "href": "/api/svm/svms/73b41add-0450-11e7-a1f7-00a09876f5a4" } } } }, "_links": { "self": { "href": "/api/snapmirror/relationships/000e6732-d8a1-11e9-8b45-00a098b98617/?list_destinations_only=true" } } }, { "uuid": "0017b348-5cab-11ea-ab11-00a098efcbcb", "source": { "path": "con-svm-201:SL10280", "svm": { "uuid": "73b41add-0450-11e7-a1f7-00a09876f5a4", "name": "con-svm-201", "_links": { "self": { "href": "/api/svm/svms/73b41add-0450-11e7-a1f7-00a09876f5a4" } } } }, "_links": { "self": { "href": "/api/snapmirror/relationships/0017b348-5cab-11ea-ab11-00a098efcbcb/?list_destinations_only=true" } } }, ...     ... View more

We are testing some functionality in the new REST API, and I have been having issues with updating volume comments on a couple filers. Filers I have tested on are running: NetApp Release 9.7P11D1: Wed Jan 27 17:40:19 UTC 2021 NetApp Release 9.7P8: Thu Oct 15 04:11:57 UTC 2020 NetApp Release 9.8P4: Mon May 03 09:22:00 UTC 2021 I suspect there is some issue with the job control in some way, but I have not been able to verify. Have poked around in logs in systemshell as well as checked 'job history show' for any clues. I submitted a case to Support and they suggested I ask here.   The program I am using to do the updates: import netapp_ontap from netapp_ontap import config, HostConnection, NetAppRestError, utils from netapp_ontap.resources import Svm, Volume, Aggregate, VolumeMetrics, Cluster, Node, CLI from pprint import pprint as pp import logging logger = logging.getLogger() logger.setLevel(logging.DEBUG) ch = logging.StreamHandler() ch.setLevel(logging.DEBUG) logger.addHandler(ch) utils.DEBUG = 1 utils.LOG_ALL_API_CALLS = 1 naauth = {'username': <USER> , 'password': <PASS>} admin = <FILER> with HostConnection(admin, verify=False, **naauth): netapp_ontap.host_connection._HOST_CONTEXT.port=<PORT> resource = Volume(uuid='dbdccb94-c936-11eb-b0cb-00a098ce3ae6') resource.comment = "testingacomment" result = resource.patch() if result.is_err: logger.error(f"Volume Comment Update Failed - {result.http_response.status_code} - {result.http_response.reason}")   The Responses from the API: -----------REQUEST----------- PATCH https://[filer]:[port]/api/storage/volumes/dbdccb94-c936-11eb-b0cb-00a098ce3ae6 User-Agent: python-requests/2.26.0 Accept-Encoding: gzip, deflate Accept: */* Connection: keep-alive X-Dot-Client-App: netapp-ontap-python-9.9.1.0 Content-Type: application/json Content-Length: 30 b'{"comment": "testingacomment"}' ----------------------------- -----------RESPONSE----------- 202 Accepted Date: Tue, 07 Sep 2021 16:22:57 GMT Server: libzapid-httpd X-Content-Type-Options: nosniff Cache-Control: no-cache,no-store,must-revalidate Content-Length: 189 Content-Type: application/hal+json Keep-Alive: timeout=5, max=100 Connection: Keep-Alive { "job": { "uuid": "dccd0527-0ff7-11ec-bbe3-00a098ef3e3a", "_links": { "self": { "href": "/api/cluster/jobs/dccd0527-0ff7-11ec-bbe3-00a098ef3e3a" } } } } ------------------------------ https://[filer]:[port] "GET /api/cluster/jobs/dccd0527-0ff7-11ec-bbe3-00a098ef3e3a?fields=message%2Cstate HTTP/1.1" 200 220 -----------REQUEST----------- GET https://[filer]:[port]/api/cluster/jobs/dccd0527-0ff7-11ec-bbe3-00a098ef3e3a?fields=message%2Cstate User-Agent: python-requests/2.26.0 Accept-Encoding: gzip, deflate Accept: */* Connection: keep-alive X-Dot-Client-App: netapp-ontap-python-9.9.1.0 None ----------------------------- -----------RESPONSE----------- 200 OK Date: Tue, 07 Sep 2021 16:22:58 GMT Server: libzapid-httpd X-Content-Type-Options: nosniff Cache-Control: no-cache,no-store,must-revalidate Content-Length: 220 Content-Type: application/hal+json Keep-Alive: timeout=5, max=99 Connection: Keep-Alive { "uuid": "dccd0527-0ff7-11ec-bbe3-00a098ef3e3a", "state": "failure", "message": "entry doesn't exist", "_links": { "self": { "href": "/api/cluster/jobs/dccd0527-0ff7-11ec-bbe3-00a098ef3e3a" } } } ------------------------------ Job (failure): entry doesn't exist. Timeout remaining: 30. ... View more

We have an interesting case here. Bit older Ontap version, 9.7, but may apply to newer versions too. Also a bit of show stopper for our ongoing zapi-to-rest porting, otherwise progressing very well, and rest apis both performing well and simplifying existing code greatly.   Problem:   As documented https://library.netapp.com/ecmdocs/ECMLP2862544/html/, this should work, but as the test below show, it does not, ontap rest cli passthrough is not retreiving the available_size field even though that field is visible in the vserver CLI console, under exact same user/lif.   Documentation states the security for both console CLI and ontap cli passthru is exactly the same: Security: All CLI-based REST APIs are RBAC-controlled, based on the role of the authenticated user and have the same protections they have in the CLI. Ontap CLI console, at SVM lif, shows all the fields we need, especially the aggr available size: devzzy::> vserver show-aggregates Available Vserver Aggregate State Size Type SnapLock Type -------------- -------------- ------- ---------- ------- -------------- devzzy dev_stor_01_ssd1 online 14.09TB ssd non-snaplock devzzy dev_stor_02_ssd1 online 16.34TB ssd non-snaplock 2 entries were displayed. devzzy::> version NetApp Release 9.7P13: Thu Apr 15 02:06:46 UTC 2021 Ontap REST to CLI passthrough, showing nothing but vserver and aggr name and ignores the fields required. At he end, positive test confirming the calling syntax is ok: simacr@simacr-linux:~$curl --insecure --user user:pass "https://devzzy/api/private/cli/vserver/aggregates" { "records": [ { "vserver": "devzzy", "aggregate": "dev_stor_01_ssd1" }, { "vserver": "devzzy", "aggregate": "dev_stor_02_ssd1" } ], "num_records": 2 } simacr@simacr-linux:~$ curl --insecure --user user:pass "https://devzzy/api/private/cli/vserver/aggregates?fields=available_size" { "error": { "message": "The value \"available_size\" is invalid for field \"fields\" (<field,...>)", "code": "262197", "target": "fields" } }simacr@simacr-linux:~$ curl --insecure --user user:pass "https://devzzy/api/private/cli/vserver/aggregates?fields=size" { "error": { "message": "The value \"size\" is invalid for field \"fields\" (<field,...>)", "code": "262197", "target": "fields" } }simacr@simacr-linux:~$ curl --insecure --user user:pass "https://devzzy/api/private/cli/vserver/aggregates?fields=state" { "error": { "message": "The value \"state\" is invalid for field \"fields\" (<field,...>)", "code": "262197", "target": "fields" } }simacr@simacr-linux:~$ curl --insecure --user user:pass "https://devzzy/api/private/cli/vserver/aggregates?fields=vserver" { "records": [ { "vserver": "devzzy", "aggregate": "dev_stor_01_ssd1" }, { "vserver": "devzzy", "aggregate": "dev_stor_02_ssd1" } ], "num_records": 2 }     ... View more