rose sphinx
Occasionally, REST GET call to /storage/volumes/{volume.uuid}/top-metrics/files returns entries like the ones below among other properly resolves entries:
{8ccda15d-8ee6-11ee-bf15-d039eaa46470.48246}
{8ccda15d-8ee6-11ee-bf15-d039eaa46470.48254}
etc.
Any ideas what may cause these entries to show up 'unresolved' ?
The inode numbers are valid and can be resolved to a file path via 'file -show-inode -inode-number'
Thank you!
timid trellis
This type of behavior generally points to an underlying issue with the API service processing the request.
I'd recommend opening a support ticket. Be sure to provide 'expected' output and 'unexpected' output examples.
tawdry gulch
Also, do consider the volume.get() (or any get) takes some time to complete. So what you may be observing as returned volume detail is nothing but the incomplete data not yet refilled from the server. This is just a guess, not knowing the context of the problem and assuming you use python client library (but it is applicable in general). But do check the Volume.get() documentation and the details on NetappResponse structure returned, especially is_job and poll at https://library.netapp.com/ecmdocs/ECMLP2886776/html/response.html
timid trellis
That’s a solid possibility. Be sure to narrow your query to the specific attributes you need.
tawdry gulch
I may be wrong about GET being async... The doc says post,patch and delete are the ones that can run asynchronously, but does not mentions get... https://library.netapp.com/ecmdocs/ECMLP2886776/html/index.html#asynchronous-processing-and-jobs
rose sphinx
hello and thank you for thoughts and suggestions
rose sphinx
James, yes, we use TopMetricsFile from netapp_ontap.resources
the call is already specific, in a sense that it is for iops.read or iops.write
Robert, whatever TopMetricsFile module returns is what we capture (presumingly it already handles the case of jobs and polls)